Cómo detectar técnicas de inyección SQL y ataques de scripts entre sitios

En los últimos dos años, los expertos en seguridad deberían haber prestado más atención a los ataques en la capa de aplicaciones de red. Porque no importa cuán fuertes sean sus reglas de firewall o cuán diligente sea para parchearlas, si los desarrolladores de sus aplicaciones web no las desarrollan con código seguro, los atacantes ingresarán a su sistema a través del puerto 80. Las dos técnicas de ataque principales que se utilizan ampliamente son los ataques de inyección SQL [ref1] y CSS [ref2]. La inyección SQL

se refiere a la tecnología de insertar metacaracteres SQL (los caracteres especiales

representan algunos datos) e instrucciones a través del área de entrada de Internet para manipular la ejecución de consultas SQL back-end. . Estos ataques se dirigen principalmente a servidores WEB de otras organizaciones. Los ataques CSS funcionan insertando etiquetas de script en las URL y luego

induciendo a los usuarios que confían en ellas a hacer clic en ellas, asegurando que el código Javascript malicioso se ejecute en la máquina de la víctima. Estos ataques se aprovechan de la relación de confianza entre el usuario y el servidor. De hecho, el servidor no detecta la entrada ni la salida y, por tanto, no rechaza el código javascript.

Este artículo analiza técnicas de detección de vulnerabilidades de inyección SQL y ataques CSS. Ha habido muchas discusiones en Internet sobre estos dos ataques basados ​​en WEB, como cómo implementar los ataques, su impacto y cómo preparar y diseñar mejor programas para prevenir estos ataques. Sin embargo,

no hay suficiente discusión sobre cómo detectar estos ataques. Usamos el popular IDS Snort de código abierto [ref

3] para formular expresiones regulares basadas en reglas para detectar estos ataques. Por cierto, la configuración de reglas predeterminada de Snort incluye métodos para detectar CSS, pero estos se pueden evitar fácilmente. Por ejemplo, la mayoría de los códigos están codificados en formato hexadecimal, como 3C7363726970 743E, para evitar la detección.

Dependiendo del nivel de

capacidades de la organización paranoia, hemos escrito múltiples reglas para detectar el mismo ataque. Si desea detectar todos los posibles ataques de inyección SQL, simplemente debe estar atento a los

metacaracteres SQL existentes, como comillas simples, punto y coma y guiones dobles. Otra forma extrema de detectar ataques CSS es simplemente tener cuidado con los corchetes angulares en las etiquetas HTML. Pero esto detectará

muchos errores. Para evitarlo, es necesario modificar las reglas para hacer más precisa su detección, sin evitar errores.

Utilice la palabra clave pcre(Perl

Expresiones regulares compatibles

)[ref4] en las reglas de Snort. Cada regla se puede aplicar con o sin otras acciones de regla. . Estas reglas también pueden ser utilizadas por software público como grep (una herramienta de búsqueda de documentos) para revisar los registros del servidor de red. Sin embargo, debe tener cuidado de que el servidor WEB registrará la entrada del usuario en el diario solo cuando la solicitud se envíe con GET. Si la solicitud se envía con POST, no se registrará en el diario.

2. Expresiones regulares para inyección SQL

Cuando

se elige una expresión regular para un ataque de inyección SQL, es importante recordar que un atacante puede enviar También se puede realizar un formulario para inyección SQL a través del área de Cookies. Su lógica de detección de entradas debe considerar varios tipos de entradas de la organización del usuario (como información de formularios o cookies). Y si encuentra muchas advertencias provenientes de una regla, tenga en cuenta las comillas simples o el punto y coma, ya que pueden ser caracteres creados por su aplicación web

Entrada legal en Cookies. Por lo tanto, debe evaluar cada regla con respecto a su aplicación web particular.

Como se mencionó anteriormente, una expresión regular detallada para detectar ataques de inyección SQL debe prestar atención a los metacaracteres especiales de SQL, como las comillas simples (') y los signos de doble expansión (--). detectar Para estos caracteres y sus equivalentes hexadecimales, se aplican las siguientes expresiones regulares:

2.1 Expresión regular para detectar metacaracteres SQL

/(\27)|(\')| (\-\-)|(\23)|(#)/ix

Explicación:

Nosotros

Primero verificamos el equivalente hexadecimal de las comillas simples , una comilla simple propiamente dicha o una doble marca de expansión. Estos son caracteres de MS SQL Server u Oracle, lo que indica que lo que sigue es un comentario.

Lo que sigue será ignorado. Además, si utiliza MySQL, debe tener cuidado con la aparición de '#' y su equivalente hexadecimal. Tenga en cuenta que no es necesario comprobar el equivalente hexadecimal del doble guión, ya que no es un metacarácter HTML y el navegador no lo codificará. Además,

Si un atacante logra modificar manualmente el doble guión a su valor hexadecimal de 2D (usando un proxy como Achilles [ref 5]), la inyección SQL fallará.

La nueva regla de Snort agregada a la expresión regular anterior es la siguiente:

alert

tcp $EXTERNAL_NET any -gt $HTTP_SERVERS $HTTP_PORTS (msg: "SQL

Inyección - Paranoico";

flujo: to_server, establecido; uricontent: ".pl"; pcre: "/(\27)|(\')|(\ -\ -)|(23)|(#)/i";

tipo de clase: ataque-aplicación-web; sid: 9099; rev: 5;)

En esta discusión ,

El valor de la palabra clave uricontent es ".pl", porque en nuestro entorno de prueba, el programa CGI

está escrito en Perl. El valor de la palabra clave uricontent depende de su aplicación particular. Este valor puede ser ".php", ".asp" o ".jsp

", etc. Desde este punto de vista, no mostramos las reglas de Snort correspondientes, pero damos las expresiones regulares que crean estas reglas.

Puedes crear fácilmente muchas reglas de Snort a través de estas expresiones regulares. En las expresiones regulares anteriores,

Detectamos guiones dobles porque: incluso si no hay comillas simples, también puede haber SQL. puntos de inyección [ref 6]. Por ejemplo, la entrada de la consulta SQL solo contiene valores numéricos, como sigue:

seleccione valor1, valor2, num_valor3 de la base de datos

donde num_valor3=algún_número_suministrado_por_el_usuario

En este En este caso, el atacante puede ejecutar consultas SQL adicionales. La demostración envía la siguiente entrada:

3; inserte valores en some_other_table

Finalmente, los modificadores pcre 'i' y '. x' se utilizan para hacer coincidir respectivamente el caso e ignorar los espacios en blanco. Las reglas anteriores también se pueden ampliar para comprobar la presencia de punto y coma. Sin embargo, el punto y coma bien puede ser parte de una respuesta HTTP normal.

Para reducir este error y evitar cualquier aparición normal de comillas simples y signos de doble expansión,

las reglas anteriores deben modificarse para detectar primero la presencia de los signos =. La entrada del usuario responderá a una solicitud GET o POST. Generalmente, la entrada se envía de la siguiente manera:

username=some_user_supplied_value&password=some_user_supplied_value

Por lo tanto, un intento de inyección SQL hará que la entrada del usuario. aparecen en un número = o su valor hexadecimal equivalente.

2.2 Corregir la expresión regular para detectar metacaracteres SQL

/((\3D)|(=))[^\n]*((\27)|(\ ')|(\-\-)|(\3B)|(:))/i

Explicación:

Esta regla primero presta atención al signo = o su valor hexadecimal (3D), luego considera cero o más caracteres arbitrarios, excepto líneas nuevas, y finalmente detecta comillas simples, guiones dobles o punto y coma.

La inyección SQL típica

intentará manipular la consulta original mediante el uso de comillas simples para obtener un valor útil. Cuando se habla de este ataque, generalmente se usa la cadena 1'or'1'='1. Sin embargo,

La detección de esta cadena se puede evadir fácilmente, como usar 1'or2gt;1 --.

Sin embargo, la única parte constante es el valor del carácter inicial, seguido de una comilla simple, seguido de 'o'. La lógica booleana que sigue puede variar en una variedad de estilos, desde ordinario hasta muy complejo. Estos ataques pueden

detectarse con considerable precisión utilizando la siguiente expresión regular. El Capítulo 2.3 lo explica.

2.3 Expresiones regulares típicas para ataques de inyección SQL

/\w*((\27)|(\'))((\6F)|o|(\4F )) ((\72)|r|(\52))/ix

Explicación:

\w* - cero o más caracteres o guiones bajos.

(\27)|\’: una comilla simple o su equivalente hexadecimal.

(\6 F)|o|(\4 F))((\72)|r|-(\52) - el caso de 'o' y su equivalente hexadecimal.

p>

'union'SQL

La consulta también es muy común en ataques de inyección SQL en varias bases de datos si la expresión regular anterior solo detecta comillas simples u otros metacaracteres SQL

, causará muchos errores. Debe modificar aún más la consulta para detectar comillas simples y la palabra clave 'union'. Esto también se puede ampliar con otras palabras clave SQL, como 'select',