Cortafuegos de aplicaciones web
Los firewalls de aplicaciones web (WAF) son un tipo de sistema de detección y prevención de intrusos y pueden ser una solución de hardware o software. Está específicamente diseñado para inspeccionar HTTP (s) y analizar las solicitudes GET y POST utilizando la lógica de detección atroz que se explica a continuación. El software de firewall de aplicaciones web generalmente está disponible como un complemento de servidor web.
WAF se ha vuelto extremadamente popular y varias compañías ofrecen una variedad de soluciones en diferentes categorías de precios, desde pequeñas empresas hasta grandes corporaciones. El WAF moderno es popular porque tiene una amplia gama de tareas cubiertas, por lo que los desarrolladores de aplicaciones web pueden confiar en él para varios problemas de seguridad, pero suponiendo que esta solución no puede garantizar una protección absoluta. A continuación se muestra un flujo de trabajo WAF básico.
Su función principal es la detección y el bloqueo de consultas en las que, según el análisis WAF, hay algunas anomalías o se rastrea un vector de ataque. Tal análisis no debería dificultar que los usuarios legítimos interactúen con una aplicación web, pero, al mismo tiempo, debe detectar de manera precisa y oportuna cualquier intento de ataque. Para implementar esta funcionalidad, los desarrolladores de WAF generalmente usan expresiones regulares, tokens, análisis de comportamiento, análisis de reputación y aprendizaje automático, y, a menudo, todas estas tecnologías se usan juntas.
Además, WAF también puede proporcionar otra funcionalidad: protección contra DDoS, bloqueo de direcciones IP de atacantes, seguimiento de direcciones IP sospechosas, agregar un indicador de solo HTTP a la cookie o agregar la funcionalidad de tokens CSRF. Cada WAF es individual y tiene una disposición interna única, pero existen algunos métodos típicos utilizados para el análisis.
Expresión regular
La mayoría de los WAF existentes se basan en reglas basadas en expresiones regulares. Para crearlos, el desarrollador WAF estudia algunos conjuntos de ataques bien conocidos y, en consecuencia, se determinan las construcciones sintácticas clave, cuya presencia se puede afirmar que lleva a cabo el ataque. En base a los resultados obtenidos, se escriben expresiones regulares que pueden encontrar tales construcciones. Por ejemplo, al analizar los encabezados HTTP como Servidor: Apache Tomcat / 7.0.x, WAF puede bloquear una respuesta y, por lo tanto, evitar la fuga de información del servidor o, como alternativa, generar una alerta.
Sin embargo, este enfoque tiene una serie de inconvenientes. El rango de aplicabilidad de una expresión regular se limita a una consulta y, a menudo, incluso a un parámetro de consulta específico, lo que obviamente reduce la efectividad de tales solicitudes. En segundo lugar, la sintaxis de las expresiones regulares, la lógica compleja de los protocolos de texto, que permiten el reemplazo de construcciones equivalentes y el uso de diferentes representaciones de símbolos, conducen a errores al crear tales reglas. La siguiente tabla muestra las técnicas de derivación más comunes.
Ofuscación de SQL. Es posible cambiar la expresión para que, utilizando la sintaxis del lenguaje, pueda eliminar espacios. Por ejemplo, en SQL, puede usar corchetes y estrellas:
s / * / e / ** // * e * // * / l / * le * c * // * / ect ~~ / ** / 1 o / id = 1 + un / ** / ion + sel / ** / ect + 1,2,3--
El otro se basa en el uso de diferentes codificaciones de tal manera que el WAF no decodifica los datos en ciertos lugares. Por ejemplo, después de reemplazar un carácter con su código url en el proceso de normalización, WAF no podrá comprender que es necesario decodificar los datos y omitir la solicitud, mientras que el mismo parámetro será aceptado y decodificado con éxito por la web aplicación
Busque construcciones sintácticas equivalentes atípicas. Este método se utiliza para encontrar una forma de operación que los desarrolladores de WAF no puedan considerar, o el vector estaba ausente en la muestra de estudio para el aprendizaje automático. Una de estas construcciones es la representación de código Javascript no alfanumérico, cuyo ejemplo se muestra a continuación.
Método de construcción de puntaje
Este enfoque no detecta ataques, pero complementa otros métodos, haciéndolos más precisos y flexibles. El motivo de la introducción de la herramienta es que la presencia en la consulta de algún diseño sospechoso es insuficiente para detectar un ataque o, por el contrario, puede provocar una gran cantidad de errores falsos positivos. Este problema se resuelve introduciendo un sistema de puntuación. Por ejemplo, cada regla basada en expresiones regulares se complementa con información sobre la importancia de su funcionamiento; Después de identificar todas las reglas trabajadas, se resume su criticidad. En el caso de superar un cierto valor umbral, se detecta el ataque y se bloquea la solicitud.
Análisis de comportamiento.
Detectar intentos de explotar vulnerabilidades en los parámetros de consulta no es la única tarea de WAF. Es importante identificar el procedimiento de búsqueda de vulnerabilidad en sí, que puede manifestarse en intentos de escaneo, directorio de fuerza bruta, borrado de parámetros y otros métodos de detección de vulnerabilidad que a menudo utilizan las herramientas automatizadas, y reaccionar en consecuencia a ellos. Los WAF más avanzados incluso saben cómo construir un archivo XML con cadenas de consulta que son típicas para el comportamiento normal del usuario y bloquean los intentos de enviar solicitudes en un orden diferente al comportamiento estándar. Este mecanismo no solo contrarresta los ataques, sino que también complica el proceso de encontrar una vulnerabilidad.
Analizadores de analizadores Tokeniser
Este enfoque para detectar ataques es un concepto complejo; sin embargo, no es fácil desmontarlo en el cebador C ++ de la biblioteca Libinjection, que permite detectar de forma rápida y precisa los ataques de inyección SQL. En la actualidad, para la biblioteca Libinjection, hay puertos para varios lenguajes de programación, incluidos Java, C y Python. El mecanismo se reduce a la búsqueda de firmas, representadas como una secuencia de tokens. Algunas de las firmas se agregan a la lista negra incorporada y se consideran inaceptables o maliciosas. En otras palabras, antes de analizar cualquier consulta, primero conduce a un conjunto de tokens. Los tokens se dividen en diferentes tipos, cadena, char, operador regular, número, comentario, variable, etc.
Uno de los principales inconvenientes de este método es que es posible construir un diseño que conduzca a la formación incorrecta de tokens; por lo tanto, la firma de la solicitud será diferente de la esperada.
Los ataques dirigidos a los tokenisers están asociados con intentos de romper la lógica al dividir la solicitud en tokens utilizando token-breakers. Estos son esos símbolos que le permiten influir en la elección de un elemento de cadena para que coincida con un token específico y, por lo tanto, omitir la búsqueda mediante firmas. En acceso abierto, hay algunas hojas de trucos, obtenidas por Mysql fuzzing y la posterior verificación de consultas en Libinjection.
Análisis de reputación
El mecanismo de reputación se hereda directamente de firewalls y antivirus. Hoy en día, casi cualquier WAF incluye listas de direcciones de servicios VPN, anonimizadores, nodos de red Tor y participantes de botnets que pueden usarse para bloquear solicitudes que se originan en direcciones sospechosas. Los WAF más avanzados pueden actualizar automáticamente sus bases de datos y realizar entradas adicionales en función del tráfico analizado.
Resumen
En general, el firewall de aplicaciones web es una herramienta de protección moderna y buena, y nunca será superflua para las aplicaciones web. La idea principal de encontrar formas de evitar WAF es llevar la consulta solicitada a un formulario en el que todavía sea comprensible para la aplicación web atacada, pero no sea comprensible o parezca inofensivo para WAF.
Sin embargo, hay varias clases de vulnerabilidades que WAF no puede detectar. Esto puede ser cualquier vulnerabilidad lógica, en este caso no hay comportamientos anormales en las solicitudes. Además, algunos estudios realizados para optimizar las reglas WAF también muestran métodos para excluir solicitudes legítimas del proceso de inspección, que pueden ser potencialmente peligrosas. Es muy probable que WAF no sea útil para identificar rivales, como la condición de la carrera y la autenticación de usuarios inseguros.
Referencia
Vladimir Ivanov (2016) Tablas de símbolos permitidos en diferentes entradas de expresión SQL, resultado del análisis de tablas fuzz. Disponible en: www.blackhat.com/docs/us-16/materials/us- 16-Ivanov-Web-Application-Firewalls-Analysis-Of-Detection-Logic.pdf
Torrano-Giménez, C., Pérez-Villegas, A. y Álvarez, G. (2009) 'Un firewall de aplicación web basado en anomalías de autoaprendizaje', Springer, Berlín, Heidelberg. doi: doi.org/10.1007/978-3-642-04091-7_11 .
Ramsingh, C. y Centonze, P. (2017) 'Análisis de programas para inyecciones de bases de datos', REVISTA INTERNACIONAL DE COMPUTADORAS Y TECNOLOGÍA, 16 (6), pp. 6977-6986. Doi: 10.24297 / ijct.v16i6.6332.
Prokhorenko, V., Choo, KKR y Ashman, H. (2016) 'Técnicas de protección de aplicaciones web: una taxonomía', Journal of Network and Computer Applications, 60, pp. 95-112. doi: 10.1016 / j.jnca.2015.11.11.017.
Prandl, S., Lazarescu, M. y Pham, D. (2015). Un estudio de soluciones de firewall de aplicaciones web. Seguridad de sistemas de información, pp. 501-510. doi: 10.1007 / 978-3-319-26961-0_29.
Positive-Technologies (2016a) 'Cortafuegos de aplicaciones web: Atacar mecanismos de lógica de detección'. Disponible en: www.blackhat.com/docs/us-16/materials/us-16-Ivanov- Web-Application-Firewalls-Analysis-Of-Detection-Logic.pdf.
OWASP (2017) Inyección SQL sin pasar por WAF. Disponible en: www.owasp.org/index.php/SQL_Injection_Bypassing_WAF .