Owl for IIS para Windows

Su aplicación web está recibiendo entradas a través de parámetros de consulta y de post. La entrada puede producir scripting entre sitios, inyección SQL y otras brechas de seguridad. Hasta ahora sabemos que WAF tiene limitaciones ya que no se ejecuta en el proceso, sino en la red: 1. Algunos pueden depender de claves SSL cuando el tráfico está cifrado. Esos no pueden manejar el caso DH 2. No puede estar seguro de qué usuario es responsable de qué declaraciones SQL, ya que el proceso puede utilizar un usuario diferente para ejecutar las SQL 3. La manipulación sofisticada de URL puede engañar al WAF 4. Un desarrollador puede establecer una puerta trasera en la aplicación (activada por un parámetro de consulta adicional para finalmente ejecutar código malicioso dedicado). ¿Cómo puede el WAF darse cuenta de eso?

Tomemos el siguiente ejemplo: el navegador del usuario está enviando esta solicitud HTTP para obtener una lista de usuarios en el departamento http://applicationHost/getData.aspx?code=derpatment. Pero el usuario también puede cambiar manualmente a un valor de código diferente como http://applicationHost/getData.aspx?code=company. Además de eso, digamos que las SQL se están ejecutando mediante un grupo de hilos que se autentican utilizando un usuario genérico. 1. La herramienta de base de datos no puede decir quién originó la solicitud. 2. El WAF necesita ser sofisticado para darse cuenta de que algo está mal con la URL.

La única opción que tiene para correlacionar los detalles del usuario (nombre e IP) con la declaración SQL exacta que la aplicación está ejecutando es estar en el punto donde la aplicación está enviando la declaración SQL fuera del proceso. Esa es la SQL real después de que la aplicación completa el procesamiento de la entrada. Sin heurísticas, sin falsos positivos. Owl para IIS tiene como objetivo exponer todas las declaraciones SQL.