ModSecurity SecRule baseado no URL original do navegador, não na reescrita interna (index.php, app.php, etc.)

Question

Estou trabalhando em um site do Symfony 2 e estou tentando criar uma regra do ModSecurity para corresponder a um URL específico do navegador. IE example.com/results

O Symfony 2 reescreve internamente todos os pedidos para app.php usando regras em .htaccess, então quando eu verifico REQUEST_URI na regra do ModSecurity, ele é configurado para app.php. Eu tentei qualquer outro parâmetro do servidor que pareça relevante, mas todos são app.php ou em branco.

Existe alguma maneira de criar uma regra do ModSecurity em um arquivo de configuração baseado na URL solicitada pelo navegador, em vez de no resultado de uma reescrita interna?

O mesmo problema parece existir com o wordpress do CMS: tudo é reescrito para index.php, então não consigo encontrar nenhuma maneira de aplicar regras modsec a uma rota específica. (Eu percebi que, como o WP é tão comum, posso encontrar uma resposta procurando o mesmo problema lá.)

    

Answer 1

It looks like I can use the server variable THE_REQUEST, as per this answer: https://stackoverflow.com/a/27968463/160565

:

I'm using mod_rewrite to dump THE_REQUEST into an environment variable just above the mod_security rules, then matching on that.

Como observado, THE_REQUEST é uma variável do servidor Apache usada por mod_rewrite, não uma variável mod_security. A variável diretamente equivalente em mod_security é REQUEST_LINE , ie. a primeira linha do pedido. Isto toma a forma de uma string como:

GET /foo/bar HTTP/1.1

A variável

THE_REQUEST (mod_rewrite) não muda quando a URL é reescrita, enquanto REQUEST_URI (mod_rewrite) faz.

No entanto, estou um pouco surpreso que a variável REQUEST_URI (mod_security) esteja retornando a URL reescrita (talvez isso tenha a ver com a ordenação de diretivas ou usando mod_security incorporado ?), em vez do URL originalmente solicitado, a menos que você esteja realmente usando a variável REQUEST_URI (mod_rewrite) (atribuindo isso a um env var?) na sua regra mod_security?

just above the mod_security rules...

As regras do mod_security provavelmente devem estar no topo do seu arquivo, se não já, antes de qualquer diretiva mod_rewrite. (Embora a ordem realmente importe, não tenho certeza.)

Note que a variável REQUEST_URI (mod_security) não é a mesma que a variável REQUEST_URI (mod_rewrite), apesar de ter o mesmo nome. Notavelmente, REQUEST_URI (mod_security) contém a string de consulta, enquanto REQUEST_URI (mod_rewrite) não.

Referência:

• link

ATUALIZAÇÃO:

... the REQUEST_URI (mod_security) variable is returning the rewritten URL

Você pode estar executando a regra mod_security muito tarde na solicitação, isto é. no errado phase ? Para processar o URL solicitado , você deve comparar com REQUEST_URI em fase 1 ou 2 (a solicitação). As fases posteriores (ou seja, 3 a 5) serão processadas em relação à resposta, o que pode explicar por que você está vendo a URL reescrita e não a URL solicitada.

O phase está definido no argumento action ou na diretiva SetDefaultAction . Por exemplo:

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

As cinco fases são:

1. Request headers (REQUEST_HEADERS)
2. Request body (REQUEST_BODY)
3. Response headers (RESPONSE_HEADERS)
4. Response body (RESPONSE_BODY)
5. Logging (LOGGING)

Starting in ModSecurity version v2.7 there are aliases for some phase numbers:

2 - request
4 - response
5 - logging

Example:

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

Referência:

• link
• link
• link

Answer 2

Parece que posso usar a variável de servidor THE_REQUEST, conforme esta resposta: link