Defensa genérica contra inyección SQL

El único enfoque genérico para prevenir la inyección de SQL es utilizar consultas parametrizadas, también conocidas como declaraciones preparadas. Estos esencialmente separan los datos del lenguaje de consulta en el nivel del protocolo, por lo que el software DBMS no intentará analizar ningún lenguaje de consulta de los parámetros.

El mecanismo que describiste parece que está filtrando solicitudes con patrones de lista negra, lo que no es necesariamente algo malo (¡la defensa en profundidad es buena!) pero parece bastante redundante si las consultas se manejan correctamente y nunca pueden reemplazar la seguridad real sólida prácticas.

El Firewall de aplicaciones web como Modsecurity es solo una medida de seguridad de operación para proteger la aplicación web de entradas maliciosas. WAF es solo un filtro de capa de aplicación que puede comparar cada solicitud y respuesta con la firma maliciosa proporcionada en el conjunto de reglas de WAF. Modsecurity Core Rule proporciona un conjunto de reglas genérico completo contra diferentes variaciones de ataques. La calidad de WAF depende de la calidad de las firmas que usa y no funcionará a menos que el administrador del sistema las ajuste a sus necesidades y descarte las reglas que causan falsos positivos. Pero desafortunadamente esto requiere un esfuerzo serio y un conocimiento profundo. Yo dividiría la seguridad en tres fases

1. Fase de desarrollo (Siga las prácticas de programación seguras)
2. Fase de implementación (endurecimiento de la aplicación a través de Selinux, apparmor)
3. Fase operativa (Seguridad operacional a través de WAF como Modsecurity)

Continuando desde mi perorata en respuesta a Polinomio;) ....

El escape adecuado de los parámetros de los parámetros es una medida preventiva muy básica, y el uso de la vinculación de parámetros es una forma de lograrlo.

Otro método (complementario) para proteger sus datos es no permitir la interacción directa con los datos subyacentes a la sesión desde el nivel lógico. No permita que la cuenta del servidor web SELECCIONE / ACTUALICE / ELIMINE / INSERTE ... etc. en su tablas de datos: en su lugar, les permiten ejecutar funciones y procedimientos (que tienen autoridad delegada). Pero esto requiere un nivel adicional para implementarse en bases de datos que no admiten idiomas de procedimiento / permisos transferidos.

Como dice Ali Ahmad, debe configurar las herramientas a su disposición para que funcionen bien juntos. No hay circunstancias de una configuración que se adapten a todos.

Mi preferencia por los entornos de alta seguridad es requerir una traducción de idioma, es decir, si mi aplicación está escrita en PHP, luego paso los parámetros de consulta a una aplicación que no es PHP para hacer la consulta; Esto agrega algo de latencia y sobrecarga computacional. Si está protegiendo las Cosas que Importan (tm), esto vale la pena fácilmente, si está protegiendo a Lolz tal vez no.

En caso de que no esté claro, en lugar de tomar parámetros de un usuario, desinfectarlos y enviarlos a una base de datos SQL, tomo los parámetros del usuario, los desinfecto y luego los transfiero a un servicio de consultas que desempaqueta, desinfecta y vuelve a empacar. y se somete a un DB para su procesamiento. De esta manera, es probable que las vulnerabilidades en un idioma o API o clase de consulta, etc. no sean suficientes para permitir un compromiso. La seguridad se realiza mejor en capas, ya que es difícil ser perfecto en cualquier cosa.