Cómo romper el nivel de inyección SQL en el juego de hackers

Enciclopedia Baidu:

Los ataques de inyección SQL son algo de lo que debe preocuparse, sin importar qué tecnología de programación web utilice, y todos los marcos web deben preocuparse por esto. Debe seguir algunas reglas muy básicas:

1) Al construir sentencias SQL dinámicas, asegúrese de utilizar un mecanismo de codificación de parámetros de tipo seguro. La mayoría de las API de datos, incluidas ADO y ADO.NET, tienen soporte que le permite especificar el tipo exacto de parámetros proporcionados (por ejemplo, cadena, número entero, fecha, etc.), lo que garantiza que estos parámetros estén codificados o codificados correctamente para evitar que los piratas informáticos explotándolos. Asegúrese de utilizar estas funciones de principio a fin.

Por ejemplo, para SQL dinámico en ADO.NET, puede reescribir la declaración anterior de la siguiente manera para que sea segura:

Dim SSN as String = Request.QueryString(" SSN" )

Dim cmd As new SqlCommand("SELECT au_lname, au_fname FROM autores DONDE au_id = @au_id")

Dim param = new SqlParameter("au_id", SqlDbType.VarChar )

param.Value = SSN

cmd.Parameters.Add(param)

Esto evitará que alguien intente introducir otra expresión SQL (porque ADO .NET sabe codificar el valor de cadena de au_id), así como evitar otros problemas de datos (como conversión incorrecta de tipos numéricos, etc.). Tenga en cuenta que el diseñador TableAdapter/DataSet integrado en VS 2005 utiliza automáticamente este mecanismo, al igual que el control de fuente de datos ASP.NET 2.0.

Una percepción errónea común es que si utiliza procedimientos almacenados o un ORM, es completamente inmune a los ataques de inyección SQL. Esto es incorrecto, aun así debe asegurarse de tener cuidado al pasar datos a procedimientos almacenados o de hacerlo de forma segura cuando utilice un ORM para personalizar una consulta.

2) Realice siempre una revisión de seguridad antes de implementar su aplicación. Establezca un proceso de seguridad formal para revisar todo el código cada vez que realice una actualización. Este último punto es particularmente importante. Muchas veces he escuchado que el equipo de desarrollo realizará una revisión de seguridad muy detallada antes de publicarlo, y luego, semanas o meses después, cuando realicen algunas actualizaciones pequeñas, se saltarán la revisión de seguridad. Guan dijo: "Es solo una pequeña actualización". "Haremos una revisión de codificación más tarde". Por favor siempre haga una revisión de seguridad.

3) Nunca almacene datos confidenciales en texto claro en la base de datos. Mi opinión personal es que las contraseñas siempre deben almacenarse con hash unidireccional y ni siquiera me gusta almacenarlas cifradas. De forma predeterminada, la API de membresía de ASP.NET 2.0 hace esto automáticamente y al mismo tiempo implementa un comportamiento seguro de aleatorización SALT. Si decide crear su propia base de datos de membresía, le recomiendo que consulte el código fuente de nuestro propio proveedor de membresía que publicamos aquí. También asegúrese de cifrar la tarjeta de crédito y otros datos privados en su base de datos. De esta forma, aunque tu base de datos esté comprometida, al menos no se utilizarán los datos privados de tus clientes.

4) Asegúrese de escribir pruebas unitarias automatizadas para verificar específicamente que su capa de acceso a datos y su aplicación no sean vulnerables a ataques de inyección SQL. Hacer esto es importante para ayudar a detectar descuidos en situaciones de "solo una pequeña actualización, sin problemas de seguridad" y para proporcionar una capa adicional de seguridad para evitar introducir accidentalmente fallas de seguridad malas en su aplicación.

5) Bloquee la seguridad de su base de datos y otorgue solo los permisos mínimos necesarios para acceder a la funcionalidad de la aplicación web de la base de datos. Si la aplicación web no necesita acceso a determinadas tablas, asegúrese de que no tenga permiso para acceder a esas tablas. Si la aplicación web solo necesita acceso de solo lectura para generar informes desde su tabla de cuentas por pagar, asegúrese de deshabilitar el acceso para insertar/actualizar/eliminar a la tabla.

6) Muchos novatos utilizan el programa del sistema general anti-inyección SQL de Internet para evitar que otros realicen pruebas de inyección manuales en el encabezado de la página que necesita evitar la inyección (.

Pero si a través de SQL el analizador de inyección puede omitir fácilmente el sistema anti-inyección y analizar automáticamente sus puntos de inyección, entonces solo tomará unos minutos analizar su administrador y contraseña.

7) Para el analizador de inyección, mediante experimentos, el autor descubrió un método de prevención simple y eficaz. Primero necesitamos saber cómo funciona el analizador de inyección SQL. Durante la operación, descubrí que no era para el administrador "admin", sino para los permisos (como bandera = 1). De esta manera, no importa cómo cambie su administrador, no podrá escapar de la detección.

Paso 3: Como no podemos escapar de la detección, haremos dos, uno es un administrador ordinario y el otro es para evitar la inyección. ¿Por qué decimos esto? El autor cree que si encontramos un sistema con la mayor autoridad para crear ilusiones y atraer la detección, y el contenido aquí tiene más de mil caracteres chinos, obligará al análisis a entrar en un estado de carga completa o incluso hará que el sistema se ejecute. sin recursos y colapsando. Modifiquemos la base de datos a continuación.

⒈Modificar la estructura de la tabla. Modifique el tipo de datos del campo del administrador, cambie el tipo de texto al campo máximo 255 (en realidad es suficiente, si desea hacerlo más grande, puede elegir el tipo de nota) y configure el campo de contraseña de la misma manera.

⒉Modificar la tabla. Establezca permisos de administrador en ID1 e ingrese una gran cantidad de caracteres chinos (preferiblemente más de 100 caracteres).

⒊Coloque la contraseña de administrador real en cualquier posición después de ID2 (como ID549).

Dado que los ataques de inyección SQL tienen como objetivo programación suelta durante el desarrollo de aplicaciones, este ataque es "legal" para la mayoría de los firewalls. La solución al problema depende únicamente de una programación perfecta. Existen pocas herramientas dirigidas específicamente a ataques de inyección SQL. Wpoison es útil para el desarrollo utilizando asp y php.