☰

ModSecurity SecRule basada en la URL original del navegador, no en reescritura interna (index.php, app.php, etc.)

tag-icon • tag-icon apache-2.4 mod-rewrite wordpress mod-security
ModSecurity SecRule basada en la URL original del navegador, no en reescritura interna (index.php, app.php, etc.)

Estoy trabajando en un sitio Symfony 2 e intento crear una regla ModSecurity para que coincida con la URL de un navegador en particular. Ejemplo de IE.com/resultados

Symfony 2 reescribe internamente todas las solicitudes a app.php usando reglas en .htaccess, por lo que cuando reviso REQUEST_URI en la regla ModSecurity, se establece en app.php. Probé cualquier otro parámetro del servidor que pareciera relevante, pero todos están en app.php o en blanco.

¿Hay alguna forma de crear una regla ModSecurity en un archivo de configuración que se base en la URL solicitada por el navegador, en lugar del resultado de una reescritura interna?

El mismo problema parece existir con CMS como WordPress: todo se reescribe en index.php, por lo que no puedo encontrar ninguna forma de aplicar reglas modsec a una ruta específica. (Pensé que, dado que WP es tan común, podría encontrar una respuesta buscando el mismo problema allí).

Respuesta1

Parece que puedo usar la variable del servidor THE_REQUEST, según esta respuesta:https://stackoverflow.com/a/27968463/160565

:

Estoy usando mod_rewrite para volcar THE_REQUESTen una variable de entorno justo encima de las reglas mod_security y luego coincido con eso.

Como se señaló, THE_REQUESTes una variable del servidor Apache utilizada por mod_rewrite, no una variable mod_security. La variable directamente equivalente en mod_security es REQUEST_LINE, es decir. la primera línea de la solicitud. Esto toma la forma de una cadena como:

GET /foo/bar HTTP/1.1

THE_REQUESTLa variable (mod_rewrite) no cambia cuando se reescribe la URL, mientras que REQUEST_URI(mod_rewrite) sí.

Sin embargo, estoy un poco sorprendido de que la REQUEST_URIvariable (mod_security) devuelva la URL reescrita (tal vez esto tenga que ver con el orden de las directivas o el uso de mod_securityincorporado?), en lugar de la URL solicitada originalmente, a menos que realmente esté usando la REQUEST_URIvariable (mod_rewrite) (¿asignando esto a una var env?) en su regla mod_security?

justo encima de las reglas mod_security...

Las reglas mod_security probablemente deberían estar en la parte superior de su archivo, si no ya, antes de cualquier directiva mod_rewrite. (Aunque no estoy seguro de si el orden realmente importa).

Tenga en cuenta que la REQUEST_URIvariable (mod_security) no es la misma que la REQUEST_URIvariable (mod_rewrite), a pesar de tener el mismo nombre. En particular, REQUEST_URI(mod_security) contiene la cadena de consulta, mientras que REQUEST_URI(mod_rewrite) no.

Referencia:

ACTUALIZAR:

... la REQUEST_URIvariable (mod_security) devuelve la URL reescrita

Es posible que esté ejecutando la regla mod_security demasiado tarde en la solicitud, es decir. equivocado phase? para procesar elsolicitadoURL con la que deberías comparar REQUEST_URIen cualquiera de los dosfase1 o 2 (la solicitud). Las fases posteriores (es decir, 3 a 5) se procesarán en función de la respuesta, lo que puede explicar por qué ve la URL reescrita y no la URL solicitada.

El phaseestá ambientado en elacciónargumento o SetDefaultActiondirectiva. Por ejemplo:

SecDefaultAction "log,pass,phase:2,id:4"
SecRule REQUEST_URI "attack" "phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath"

Las cinco fases son:

  1. Solicitar encabezados (REQUEST_HEADERS)
  2. Cuerpo de la solicitud (REQUEST_BODY)
  3. Encabezados de respuesta (RESPONSE_HEADERS)
  4. Cuerpo de respuesta (RESPONSE_BODY)
  5. Registro (REGISTRO)

A partir de la versión v2.7 de ModSecurity, existen alias para algunos números de fase:

2 - solicitud
4 - respuesta
5 - registro

Ejemplo:

SecRule REQUEST_HEADERS:User-Agent "Test" "phase:request,log,deny,id:127"

Referencia:

Respuesta2

Parece que puedo usar la variable del servidor THE_REQUEST, según esta respuesta:https://stackoverflow.com/a/27968463/160565

información relacionada