14
ediciones
Adicion de informacion, protocolo de respuesta, ejemplo de errores y referencias. Nota: La corrección de puntuacion esta hecho por IA
Sin resumen de edición |
(Adicion de informacion, protocolo de respuesta, ejemplo de errores y referencias. Nota: La corrección de puntuacion esta hecho por IA) |
||
| Línea 118: | Línea 118: | ||
' OR '1'='1 | ' OR '1'='1 | ||
</pre> | </pre> | ||
*Si | *Si esta cadena se concatena en una consulta de autenticación sin protección, la condición lógica puede resultar siempre verdadera y permitir acceso no autorizado. Este ejemplo se usa para ilustrar el concepto; la exposición real siempre depende del contexto de la consulta y del tratamiento que haga la aplicación de la entrada. | ||
=== Tipos comunes de inyección (visión general) === | === Tipos comunes de inyección (visión general) === | ||
| Línea 144: | Línea 144: | ||
=== Prevención y mitigación (prácticas recomendadas) === | === Prevención y mitigación (prácticas recomendadas) === | ||
1. Mantener separación entre código y datos | |||
* '''Consultas preparadas / parámetros enlazados''' (prepared statements): la forma más efectiva de evitar que la entrada del usuario sea interpretada como código SQL. | * '''Consultas preparadas / parámetros enlazados''' (prepared statements): la forma más efectiva de evitar que la entrada del usuario sea interpretada como código SQL. | ||
Ejemplo en PHP (PDO): | Ejemplo en PHP (PDO): | ||
| Línea 157: | Línea 156: | ||
<pre style="color: blue"> | <pre style="color: blue"> | ||
cur.execute("SELECT * FROM usuarios WHERE correo = %s AND contraseña = %s", (correo, hash)) | cur.execute("SELECT * FROM usuarios WHERE correo = %s AND contraseña = %s", (correo, hash)) | ||
</pre> | </pre>2. Validación y saneamiento | ||
* Validar tipo, longitud, formato (ej. emails, números, fechas) antes de procesar. | * Validar tipo, longitud, formato (ej. emails, números, fechas) antes de procesar. | ||
* Rechazar o normalizar entradas inesperadas. | * Rechazar o normalizar entradas inesperadas. | ||
* Evitar la construcción dinámica de SQL con concatenación de strings. | * Evitar la construcción dinámica de SQL con concatenación de strings. | ||
3. Principio de menor privilegio | |||
* La cuenta que usa la aplicación para conectarse debe tener permisos mínimos (por ejemplo SELECT/INSERT/UPDATE en tablas necesarias, sin DROP ni DDL excesivo). | * La cuenta que usa la aplicación para conectarse debe tener permisos mínimos (por ejemplo SELECT/INSERT/UPDATE en tablas necesarias, sin DROP ni DDL excesivo). | ||
4. Uso de ORMs con cuidado | |||
* Los ORMs suelen parametrizar consultas correctamente, pero el uso de consultas «raw» o concatenadas puede introducir riesgos. Revisar y auditar el código que construye SQL manualmente. | * Los ORMs suelen parametrizar consultas correctamente, pero el uso de consultas «raw» o concatenadas puede introducir riesgos. Revisar y auditar el código que construye SQL manualmente. | ||
5. Manejo seguro de errores y mensajes | |||
* No mostrar trazas o errores SQL al usuario. Registrar internamente la información suficiente para investigar sin exponer estructura ni datos. | * No mostrar trazas o errores SQL al usuario. Registrar internamente la información suficiente para investigar sin exponer estructura ni datos. | ||
6. Registro, monitoreo y respuesta | |||
* Implementar alertas ante patrones sospechosos (picos de errores, inputs raros). | * Implementar alertas ante patrones sospechosos (picos de errores, inputs raros). | ||
* Mantener logs de consultas y accesos para análisis forense. | * Mantener logs de consultas y accesos para análisis forense. | ||
7. Controles adicionales | |||
* Web Application Firewall (WAF) como capa adicional — útil pero no sustituye buenas prácticas de codificación. | * Web Application Firewall (WAF) como capa adicional — útil pero no sustituye buenas prácticas de codificación. | ||
* Hardening y parches de la BD y del servidor de aplicaciones. | * Hardening y parches de la BD y del servidor de aplicaciones. | ||
| Línea 184: | Línea 186: | ||
=== Ejemplos de corrección (antes / después) === | === Ejemplos de corrección (antes / después) === | ||
*Código vulnerable (no usar): | *Código vulnerable (no usar): | ||
<pre style="color: red"> | <pre style="color: red"> | ||
$sql = "SELECT * FROM usuarios WHERE correo = '" . $_POST['correo'] . "' AND contraseña = '" . $_POST['pass'] . "'"; | $sql = "SELECT * FROM usuarios WHERE correo = '" . $_POST['correo'] . "' AND contraseña = '" . $_POST['pass'] . "'"; | ||
</pre> | </pre> | ||
*Corrección con prepared statement (recomendada): | *Corrección con prepared statement (recomendada): | ||
<pre style="color: blue"> | <pre style="color: blue"> | ||
$stmt = $pdo->prepare("SELECT * FROM usuarios WHERE correo = :correo AND contraseña = :pass"); | $stmt = $pdo->prepare("SELECT * FROM usuarios WHERE correo = :correo AND contraseña = :pass"); | ||
| Línea 199: | Línea 201: | ||
=== Respuesta ante un incidente === | === Respuesta ante un incidente === | ||
1. Contener: desactivar vectores afectados (ej. endpoints vulnerables), cambiar credenciales si fuera necesario. | 1. Contener: desactivar vectores afectados (ej. endpoints vulnerables), cambiar credenciales si fuera necesario. | ||
2. Analizar logs para identificar alcance y vectores. | 2. Analizar logs para identificar alcance y vectores. | ||
3. Restaurar desde backups conocidas si hay pérdida o corrupción de datos. | 3. Restaurar desde backups conocidas si hay pérdida o corrupción de datos. | ||
4. Corregir la vulnerabilidad (parche, refactorización de consultas) y ejecutar pruebas. | 4. Corregir la vulnerabilidad (parche, refactorización de consultas) y ejecutar pruebas. | ||
5. Notificar a las partes afectadas según normativa/Política de divulgación y cumplimiento legal. | 5. Notificar a las partes afectadas según normativa/Política de divulgación y cumplimiento legal. | ||
| Línea 211: | Línea 217: | ||
* Aprender SQL es clave para desarrollar con seguridad: entender cómo se construyen consultas permite tanto optimizar rendimiento como prevenir fallos de seguridad. | * Aprender SQL es clave para desarrollar con seguridad: entender cómo se construyen consultas permite tanto optimizar rendimiento como prevenir fallos de seguridad. | ||
* Revisar siempre los puntos del código que generan SQL dinámico y tratarlos como zonas críticas de seguridad. | * Revisar siempre los puntos del código que generan SQL dinámico y tratarlos como zonas críticas de seguridad. | ||
== Bibliografía == | |||
[https://pedrobeltrancanessa-biblioteca.weebly.com/uploads/1/2/4/0/12405072/fundamentos_de_sql_3edi_oppel.pdf Fundamentos de SQL - Andy Oppel Robert Sheldon] | |||
[https://es.wikipedia.org/wiki/MySQL MySQL - Wikipedia] | |||
[[index.php?title=Categoría:Bases de datos]] | [[index.php?title=Categoría:Bases de datos]] | ||