☰

Htacess Helicon APE falso positivo 403 falha

tag-icon • tag-icon iis .htaccess mod-rewrite
Htacess Helicon APE falso positivo 403 falha

Em vez de usar web.configminhas regras de reescrita, tenho usadoHélicon APEpara emular o recurso do Apache .htaccess.

Eu tenho um grande .htaccessarquivo universal que é aplicado em todo o servidor como parte de um recurso para restringir o acesso à passagem de comandos como união, exclusão etc.

No entanto, estou me deparando com um problema em que uma linha do código está criando um falso positivo e bloqueando o acesso a um URL adequado.

A URL que está falhando é:http://example.com/union-contracts

Usando o comando abaixo em web.config, todos os URLs ausentes são enviados para index.php.

   <httpErrors errorMode="Custom" existingResponse="Replace">
        <remove statusCode="404" subStatusCode="-1" />
        <error statusCode="404" path="/index.php" responseMode="ExecuteURL" />
    </httpErrors>

regra htaccess que está retornando 403

RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC]
RewriteRule . - [F,L]

Em última análise, gostaria de continuar bloqueando a união, por exemplo, só preciso modificar a linha para falsos positivos. Observe que também não estou procurando -contractsser codificado em minha .htaccessregra.

Consegui duplicar o problema no htaccess no XAMPP depois de lembrar como o URL está sendo gerado.

Do lado do visitante do site, quando uma URL é acessada o servidor gera um erro 404. Eu filtro o URL apenas para a última parte e verifico o banco de dados com relação a essa string para ver se ele corresponde a um URL salvo. Nesse caso, não passo esse 404 para o navegador, ele só é passado se o URL puder ' não ser encontrado.

Quando o IIS gera um erro 404, o URL se torna:

index.php?404;http://example.com:80/union-contracts

Mas não é passado para o navegador nesse formato.

Responder1

Expressei minha preocupação em comentários de que deve haver "alguma coisa" acontecendo, mas de qualquer maneira...

É difícil escrever uma exceção para uma regra que não deveria (leia-se: "não pode") ser acionada em primeiro lugar - é um trabalho de suposição completo. Afinal, por que oexceçãoser homenageado?

Essa regra já deveria evitar a solicitação dada por alguns "grandes" motivos:

  1. A solicitação não inclui uma string de consulta.
  2. A regex na condição (CondPadrão) não corresponde a nenhuma parte do URL (mesmo que esteja na string de consulta).

Considerando o item 2 acima, o regex já contém uma exceção suficiente para não corresponder à solicitação fornecida, então como podemos implementar “outra” exceção?

Você poderia modificar oCondPadrãopara evitar casos em que um hífen ( -) segue a palavra "união", usando umantecipação negativa. Por exemplo:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union(?!-)|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)

Portanto, o texto acima corresponde Xunion, mas não Xunion-, onde Xestá uma das sequências de caracteres do primeiroalternânciagrupo (ou seja (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00)).

Ou, quando um hífen segue qualquer uma destas palavras-chave:

(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode)(?!-)

(ATUALIZAR:As duas sugestões a seguir provavelmente não funcionarão, pois parece que as diretivas só são processadasdepoisO IIS já reescreveu o URL. Nesse ponto, o caminho da URL é simplesmente /index.php, não /union-contracts.)

Ou modifique RewriteRulepara que não corresponda quando o caminho da URL começa /union-(embora isso potencialmente forneça um backdoor para a tentativa de XSS que a regra está tentando bloquear). Por exemplo:

RewriteRule !^/?union- - [F]

(Pelo menos no Apache, o Lsinalizador não é necessário quando o Fsinalizador é usado - está implícito.)

Alternativamente, você cria outra regra noprincipal, antes de suas regras existentes, que cria uma exceção ao solicitar um URL que começa /union-e não possui uma string de consulta (embora isso pareça uma contradição, se quisermos acreditar na outra regra). Por exemplo:

RewriteCond %{QUERY_STRING} ^$
RewriteRule ^/?union- - [L]

No entanto, isso potencialmente "quebrará" a solicitação se você tiver outras regras posteriormente no arquivo que precisem reescrever a URL de alguma forma - já que isso não ocorrerá.

Estou assumindo que Helicon-APE/mod_rewrite funciona em umsemelhante a um diretóriocontexto (por exemplo, .htaccesssintaxe de estilo em oposição aservidorouhost virtualcontexto)? Embora isso não deva afetar as diretivas acima, na verdade.

ATUALIZAR:Quando o IIS gera um erro 404, o URL se torna:

index.php?404;http://example.com:80/union-contracts

Ah sim! Esse URLvaiser pego pela condição original. Então, parece que as diretivas mod_rewrite são processadasdepoisa "reescrita" do IIS no web.config! Isto torna estas directivas de "segurança" algo supérfluas ou mesmo incorrectas, uma vez que sãosupostoa ser executado na solicitação inicial do cliente. E....

Eu filtro o URL apenas até a última parte e verifico o banco de dados com essa string para ver se ele corresponde a um URL salvo

Como você está analisando ativamente o URL e filtrando apenas a parte necessária, essas verificações de "segurança" pareceriam redundantes de qualquer maneira, pelo menos para essas solicitações "404". (Na verdade, dependendo dos arquivos reais (ou seja, solicitações não 404) que poderiam ser solicitados diretamente, uma string de consulta maliciosa dessa natureza poderia representar realisticamente uma ameaça à segurança de qualquer URL?)

As duas sugestões acima para modificar o regex nodoençapara excluir instâncias quando um hífen segue a palavra-chave "união" ouqualquerpalavra-chave, ainda se aplicaria aqui e pareceria resolver o problema imediato.

Você também pode abortar todas as verificações quando uma URL do formulário index.php?404;for encontrada (ou seja, após ter sido reescrita pelo IIS). (Presumo que todas as suas diretivas mod_rewrite sejam verificações de "segurança" semelhantes?)

Por exemplo, adicione o seguinte aoprincipaldo .htaccessroteiro,antesas directivas existentes:

RewriteCond %{QUERY_STRING} ^404;
RewriteRule ^/?index\.php - [L]

Isto deve impedir qualquer processamento adicional quando um URL do formulário /index.php?404;......for encontrado. (Já que você está analisando o URL de qualquer maneira no seu script.)

informação relacionada