☰

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

tag-icon • tag-icon apache-2.4 mod-rewrite wordpress mod-security
ModSecurity SecRule baseado no URL original do navegador, não na reescrita interna (index.php, app.php, etc.)

Estou trabalhando em um site Symfony 2 e tentando criar uma regra ModSecurity para corresponder a um URL de navegador específico. IE exemplo.com/resultados

O Symfony 2 reescreve internamente todas as solicitações para app.php usando regras em .htaccess, portanto, quando eu verifico REQUEST_URI na regra ModSecurity, ele está definido como app.php. Eu tentei qualquer outro parâmetro de servidor que parecesse relevante, mas todos são app.php ou em branco.

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

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

Responder1

Parece que posso usar a variável do servidor THE_REQUEST, conforme esta resposta:https://stackoverflow.com/a/27968463/160565

:

Estou usando o mod_rewrite para despejar THE_REQUESTem uma variável de ambiente logo acima das regras do mod_security e, em seguida, combinar isso.

Conforme observado, THE_REQUESTé uma variável do servidor Apache usada pelo mod_rewrite, não uma variável mod_security. A variável diretamente equivalente em mod_security é REQUEST_LINE, ou seja. a primeira linha da solicitação. Isso assume a forma de uma string como:

GET /foo/bar HTTP/1.1

THE_REQUESTA variável (mod_rewrite) não muda quando o URL é reescrito, enquanto REQUEST_URI(mod_rewrite) muda.

No entanto, estou um pouco surpreso que a REQUEST_URIvariável (mod_security) esteja retornando a URL reescrita (talvez isso tenha a ver com a ordem das diretivas ou com o uso do mod_securityintegrado?), em vez do URL solicitado originalmente, a menos que você esteja realmente usando a REQUEST_URIvariável (mod_rewrite) (atribuindo isso a um env var?) em sua regra mod_security?

logo acima das regras mod_security...

As regras mod_security provavelmente devem estar no topo do seu arquivo, se ainda não estiverem, antes de qualquer diretiva mod_rewrite. (Embora não tenha certeza se a ordem realmente importa.)

Observe que a REQUEST_URIvariável (mod_security) não é igual à REQUEST_URIvariável (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:

ATUALIZAR:

... a REQUEST_URIvariável (mod_security) está retornando a URL reescrita

Você pode estar executando a regra mod_security muito tarde na solicitação, ou seja. no erro phase? Para processar oRequeridosREQUEST_URIURL com o qual você deve compararEstágio1 ou 2 (o pedido). As fases posteriores (ou seja, 3 a 5) serão processadas em relação à resposta, o que pode explicar por que você está vendo o URL reescrito e não o URL solicitado.

O phaseestá definido noAçãoargumento ou SetDefaultActiondiretriz. 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. Cabeçalhos de solicitação (REQUEST_HEADERS)
  2. Corpo da solicitação (REQUEST_BODY)
  3. Cabeçalhos de resposta (RESPONSE_HEADERS)
  4. Corpo da resposta (RESPONSE_BODY)
  5. Registro (LOGGING)

A partir do ModSecurity versão v2.7, existem aliases para alguns números de fase:

2 - solicitação
4 - resposta
5 - registro

Exemplo:

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

Referência:

Responder2

Parece que posso usar a variável de servidor THE_REQUEST, conforme esta resposta:https://stackoverflow.com/a/27968463/160565

informação relacionada