Inyección SQL

SQL indica a una base de datos qué registros consultar o modificar y bajo qué condiciones. Hay inyección cuando una entrada no confiable cambia esas instrucciones en lugar de permanecer como valor. Importa igual si llega desde un formulario, una cola, un socio o un registro guardado.

Enlaza valores y restringe estructura

Las consultas parametrizadas separan los valores de la sintaxis SQL. Las sentencias preparadas son una forma habitual de conseguirlo. En general, los parámetros no sustituyen nombres de tablas, columnas ni palabras de ordenación. Si el usuario elige un orden, traduce su elección a un conjunto reducido de estructuras definidas por el servidor.

Los procedimientos almacenados bien implementados también pueden ser seguros. Un procedimiento o un ORM se vuelve inseguro si construye SQL ejecutable con texto no confiable. El control es cómo se construye la consulta, no el nombre de la biblioteca. OWASP explica estas alternativas.

Escenario: el informe de la librería

La librería enlaza el autor como valor de búsqueda y permite ordenar por título o fecha. Un proceso posterior reutiliza nombres de búsquedas guardadas. Esos nombres siguen necesitando parámetros en su nuevo uso: guardar datos no los convierte en SQL confiable.

Hay inyección de segundo orden cuando datos no confiables almacenados se interpretan después como instrucciones o estructura SQL; reutilizarlos más tarde no es por sí solo inyección. Hay que conservar la frontera cada vez que un dato llega al intérprete, no solo cuando entra inicialmente.

La evidencia tiene límites

Un error puede revelar detalles de la base de datos, pero no demuestra por sí solo una inyección. Los tiempos pueden variar por carga, red u otras tareas. Una evaluación sólida combina construcción de consultas, diagnósticos autorizados y flujo de datos esperado.

Un informe distingue defectos confirmados de construcción e impacto sin verificar. No necesita recuperar registros privados para explicar que falta la separación.

Prevención y alcance del daño

Un WAF puede reducir exposición a determinadas entradas sin corregir una consulta insegura. Una cuenta de solo lectura limita escrituras, pero puede acceder a datos privados. El mínimo privilegio complementa la parametrización, no la sustituye.

Los parámetros tampoco imponen pertenencia a una organización ni reglas de negocio. Una consulta correctamente parametrizada puede devolver datos de otro cliente si falta el filtro de autorización. Pasar a NoSQL cambia el lenguaje, pero no elimina la separación entre datos y operadores.

Revisa el arreglo completo

Examina fragmentos dinámicos, enlaza valores, limita elecciones estructurales y conserva comprobaciones de acceso. Incluye procesos de fondo e informes. Documenta conducta aprobada e incertidumbre restante para verificar la corrección sin ampliar la exposición.

Separa tres requisitos en un mismo informe

La librería ficticia aporta registros de su generador de informes. Q1 vincula el valor de búsqueda de autor mediante la API de base de datos. Q2 elige la columna de ordenación desde un mapa fijo del servidor. Q3 selecciona registros sin el filtro de pertenencia a la tienda exigido por la política. La cuenta de base de datos es de solo lectura.

Q1 y Q2 tratan partes distintas de la construcción: los valores siguen siendo valores y las elecciones estructurales permanecen dentro del conjunto definido por el servidor. Ninguno aporta la condición de propiedad ausente en Q3. Solo lectura limita cambios, pero puede permitir divulgar registros de otra tienda.

PrediceEl generador parametriza todos los valores. ¿Puede el revisor aprobar el aislamiento entre tiendas?

Los registros siguen mostrando que falta la condición de propiedad requerida. La parametrización protege el límite de interpretación; la autorización decide qué registros puede devolver la consulta. El informe necesita ambas.

Incluye ahora el trabajo de informes programado. Lee filtros guardados y crea su propia petición de base de datos. Los filtros siguen siendo datos aunque una búsqueda interactiva anterior los tratara correctamente. El trabajo necesita separar valores y limitar estructuras en su propio uso, además del contexto de tienda correcto para su tarea.

Escribe criterios de aceptación separados. Para construcción, identifica cada valor variable y elección estructural, y su tratamiento en ambas rutas. Para autorización, establece que cada informe devuelve solo registros permitidos por la regla de tienda. Para autoridad, confirma que la cuenta tiene únicamente los accesos necesarios para sus funciones.

Un error inesperado justificaría diagnóstico, no afirmar que se recuperaron registros mediante inyección. Tampoco la ausencia de errores demuestra construcción correcta. Los registros de implementación sustentan una comprobación de propiedad ausente; la exposición real y el uso histórico requieren más evidencia.