¿Cómo prevenir la inyección de Sql?

(1) Para construir dinámicamente consultas SQL, se pueden utilizar las siguientes técnicas:

Primero: reemplazar comillas simples, es decir, cambiar todas las comillas simples por dos comillas simples para evitar que los atacantes modifiquen el significado de los comandos SQL. . Mirando el ejemplo anterior, "SELECCIONAR * De usuarios donde iniciar sesión = ' ' o ' ' 1 ' ' = ' 1 ' y contraseña = ' ' o ' ' 1 ' ' = ' 1 '" obviamente obtendrá el mismo resultado que "SELECCIONAR * De usuarios donde iniciar sesión = ' o ' 1 ' = ' 1 ' y contraseña = ' o ' 1 ' = ' 1 '" mismos resultados diferentes.

En segundo lugar, elimine todos los guiones de la entrada del usuario para evitar que un atacante cree una consulta como "seleccione * de los usuarios donde iniciar sesión = ' MAS '-y contraseña = ' '" porque la consulta es La segunda mitad ha sido comentado y ya no es válido. Siempre que el atacante conozca el nombre de usuario legítimo de inicio de sesión, podrá obtener acceso con éxito sin conocer la contraseña del usuario.

En tercer lugar, limite los permisos de la cuenta de base de datos utilizada para ejecutar la consulta. Utilice diferentes cuentas de usuario para realizar operaciones de consulta, inserción, actualización y eliminación. Debido a que las operaciones que pueden realizar diferentes cuentas están aisladas, también evita que la ubicación utilizada originalmente para ejecutar un comando SELECT se use para ejecutar un comando INSERT, UPDATE o DELETE.

⑵ Utilice procedimientos almacenados para ejecutar todas las consultas. Los parámetros SQL se pasan de forma que se evite que los atacantes utilicen comillas simples y guiones. Además, permite restringir los permisos de la base de datos para permitir que solo se ejecuten procedimientos almacenados específicos, y todas las entradas del usuario deben ajustarse al contexto de seguridad del procedimiento almacenado llamado, lo que dificulta los ataques de inyección.

(3) Limite la longitud del formulario o la cadena de consulta ingresada. Si el nombre de inicio de sesión del usuario tiene un máximo de 10 caracteres, entonces no reconocerá más de 10 caracteres ingresados ​​en el formulario. Esto aumentará en gran medida la dificultad para los atacantes de insertar código dañino en los comandos SQL.

(4) Verifique la legalidad de la entrada del usuario para asegurarse de que la entrada solo contenga datos legales. La verificación de datos debe realizarse tanto en el lado del cliente como en el del servidor; el motivo de la verificación del lado del servidor es compensar la frágil 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 una página web, modifique el script que verifica la legalidad (o elimine el script directamente) y luego envíe contenido ilegal al servidor en la forma modificada. Por lo tanto, la única forma de garantizar que la operación de validación realmente se haya realizado es realizarla también en el lado del servidor. Hay muchos objetos de validación integrados que puede utilizar, como RegularExpressionValidator, que puede generar automáticamente scripts de cliente para la validación. Por supuesto, también se pueden insertar llamadas a métodos del lado del servidor. Si no puede encontrar un objeto de validación listo para usar, puede crear uno usted mismo a través de CustomValidator.

⑸ 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 comando SQL. sistema. La clase de autenticación web.security.forms tiene un archivo hashpasswordforstoringconfig que es excelente para desinfectar los datos de entrada.

[6] Verifique el número de registros devueltos por la consulta que extrajo los datos. Si el programa solo solicita que se devuelva un registro, pero en realidad se devuelve más de una fila, se considera un error.

-

La clave es comprender el principio. De hecho, la prevención es muy simple

1. Filtrar caracteres confidenciales en los parámetros requeridos por SQL. tenga en cuenta que se ignora el caso).

2. Deshabilite el procedimiento almacenado xp_cmdshell del servidor de base de datos y elimine la dll correspondiente.

3. Información de excepción del servidor Shield