Evitar la inyección de SQL

Ahora que comprende el método de inyección SQL, ¿cómo prevenir la inyección SQL? ¿Cómo prevenir aún más la propagación de la inyección SQL? Reduzca el riesgo de inyección de SQL mediante algunas operaciones y configuraciones razonables.

Utilice declaraciones de filtro parametrizadas

Para evitar la inyección de SQL, la entrada del usuario no debe incrustarse directamente en la declaración SQL. En su lugar, se deben filtrar las entradas del usuario o se deben utilizar declaraciones parametrizadas. Las declaraciones parametrizadas utilizan parámetros en lugar de incorporar la entrada del usuario en la declaración. En la mayoría de los casos, se corregirá la declaración SQL. Luego limite la entrada del usuario a un parámetro.

Validación de entrada

Verifique la legalidad de la entrada del usuario para asegurarse de que la entrada solo contenga datos legales. La razón por la que se realiza la verificación del lado del servidor es para compensar la falta de seguridad del mecanismo de verificación del lado del cliente. En el lado del cliente, es completamente posible que un atacante obtenga el código fuente de la página web, modifique el script que verifica la legalidad (o elimine el script directamente) y luego envíe contenido ilegal al servidor a través del formulario modificado. Por lo tanto, la única forma de garantizar que la operación de validación se haya realizado realmente es realizarla también en el lado del servidor. Hay muchos objetos de validación integrados que puede utilizar, como el validador de expresiones regulares, que puede generar automáticamente scripts del lado del cliente para la validación, o puede insertar llamadas a métodos del lado del servidor. Si no puede encontrar un objeto de validación existente, puede crear uno usted mismo utilizando un validador personalizado.

Manejo de mensajes de error

Prevenir la inyección SQL también requiere evitar mensajes de error detallados que los piratas informáticos podrían explotar. Se deben utilizar mecanismos de validación de entrada estándar para validar todos los datos de entrada en cuanto a longitud, tipo, declaraciones, reglas de la empresa, etc.

Procesamiento de cifrado

Cifre y guarde el nombre de inicio de sesión del usuario, la contraseña y otros datos. Cifrar los datos ingresados ​​por el usuario y luego compararlos con los datos almacenados en la base de datos equivale a "esterilizar" los datos ingresados ​​por el usuario. Los datos ingresados ​​por el usuario ya no tienen ningún significado especial para la base de datos, evitando así que los atacantes. de inyectar comandos SQL.

El procedimiento almacenado que ejecuta todas las consultas

Los parámetros SQL se pasan de una manera que evita que los atacantes utilicen comillas simples y guiones. Además, puede restringir los permisos de la base de datos para permitir solo la ejecución de procedimientos almacenados específicos, y todas las entradas del usuario deben cumplir con el contexto de seguridad del procedimiento almacenado llamado, lo que dificulta los ataques de inyección.

Usando herramientas especializadas de escaneo de vulnerabilidades

Los atacantes ahora pueden buscar objetivos automáticamente y ejecutar ataques, y sus técnicas pueden incluso aplicarse fácilmente a vulnerabilidades en otras arquitecturas web. Las empresas deberían invertir en herramientas especializadas de escaneo de vulnerabilidades, como Web Vulnerability Scanner de Acunetix. Una herramienta de escaneo de vulnerabilidades completa es diferente de una herramienta de escaneo de red que busca específicamente vulnerabilidades de inyección SQL en un sitio web. Los últimos escáneres de vulnerabilidades buscan vulnerabilidades recién descubiertas.

Proteja su base de datos

Bloquee la seguridad de su base de datos, otorgue solo los permisos mínimos necesarios para acceder a la funcionalidad de la aplicación web de la base de datos, revoque permisos públicos innecesarios, utilice un cifrado sólido que proteja los datos confidenciales y mantiene un registro de auditoría. Si la aplicación web no necesita acceso a determinadas tablas, verifique que no tenga permiso para acceder a esas tablas. Si su aplicación web solo requiere acceso de solo lectura, deshabilite el acceso desplegable, de inserción, de actualización y de eliminación a la tabla, y asegúrese de que la base de datos esté actualizada con los parches más recientes.

Revisión de seguridad

Asegúrese de realizar una revisión de seguridad antes de implementar la aplicación. Establezca procesos de seguridad formales y revise toda la codificación con cada actualización. El equipo de desarrollo llevará a cabo una revisión de seguridad muy detallada antes del lanzamiento oficial y luego, cuando realicen algunas actualizaciones muy pequeñas unas semanas o meses después, se saltarán la revisión de seguridad y dirán: "Esta es sólo una pequeña actualización, "Hazlo más tarde." Se realizará una revisión de codificación más tarde." Insista siempre en una revisión de seguridad.