Os maiores problemas com isso são:
- É muito grande e complexo demais.
- Está lhe dando uma falsa sensação de segurança.
- Ele bloqueará usuários legítimos.
Os problemas com 1. são que isso causará uma carga excessiva em seu servidor processando todas essas regras para cada solicitação e que, quando as regras são complexas, até mesmo a menor alteração pode ter grandes consequências. Ser extremamente grande também torna muito difícil conhecer a coisa toda.
O problema com 2. (a falsa sensação de segurança) é que você terá menos cuidado ao escrever o código do lado do servidor ou você será mais lento atualizando aplicativos porque você tem essa proteção RewriteRule. Mais sobre por que é uma falsa sensação de segurança mais tarde.
Tenho certeza de que não preciso dizer por que bloquear usuários legítimos é um problema.
Para dar alguns exemplos:
O segundo FilesMatch no snippet a seguir é redundante. Tudo o que pode ser bloqueado pelo segundo já está bloqueado pelo primeiro:
<FilesMatch "\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>
<FilesMatch "(\.htaccess|\.htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
O FilesMatch após esses dois também corresponde de forma redundante a .htaccess arquivos novamente com esse tempo com insensibilidade a maiúsculas e minúsculas.
O segundo aqui também é redundante:
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
# Anti cross site tracing - protection
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
Algumas linhas são repetidas textualmente. Este aqui:
RewriteCond %{REQUEST_METHOD} (GET|POST) [NC]
Aparece três vezes antes do primeiro RewriteRule .
Você tem muitas RewriteCond diretivas com [OR] depois delas, mas nem todas têm essa opção. Pela minha conta, você tem 79 RewriteCond s, 10 dos quais não têm [OR] antes de seu primeiro RewriteRule . Manter o controle do que será permitido e do que não está aqui está além da minha capacidade mental.
Adicionar uma nova regra sem [OR] ou adicionar uma regra antes de RewriteRule e esquecer de adicionar [OR] ao anterior RewriteCond pode alterar a lógica de todos os outros RewriteCond s antes e depois até o próximo RewriteRule .
No lado da segurança, algumas das regras aqui são sólidas e algumas delas (como as que bloqueiam a entrega de arquivos .htaccess) são inclusas nos arquivos de configuração padrão do Apache (o que provavelmente os torna redundantes no seu arquivo .htaccess). htaccess), mas muitos deles são baseados em palavras-chave de lista negra e isso não funcionará.
Os ataques de injeção de SQL podem acontecer em qualquer parâmetro controlado pelo usuário. Você verificou uma lista de palavras-chave relacionadas a SQL em %{QUERY_STRING} e %{HTTP_COOKIE} , mas perdeu as %{REQUEST_URI} , %{HTTP_USER_AGENT} , %{HTTP_REFERER} , %{HTTP_FORWARDED} , %{HTTP_HOST} , %{HTTP_PROXY_CONNECTION} e %{HTTP_ACCEPT} . Essa não é uma lista completa de parâmetros controlados pelo usuário por qualquer meio e os invasores podem adicionar qualquer cabeçalho que quiserem a uma solicitação.
O snippet a seguir é um exemplo disso:
h%20ttp://
ht%20tp://
htt%20p://
http%20://
Um invasor pode colocar um espaço codificado por URL na string de consulta e ele ainda será analisado e solicitado corretamente. Mas você perdeu todas essas combinações:
%20http://
h%20ttp%20://
ht%20tp%20://
htt%20p%20://
ht%20t%20p%20://
h%20t%20t%20p%20://
Como essencialmente há um número infinito de strings "ruins", tentar enumerá-las em um arquivo .htaccess é fútil.
Existem folhas de dicas para Injeção de SQL e XSS projetado precisamente para evitar a filtragem desse tipo.
O bloqueio de usuários legítimos é surpreendentemente fácil. As strings de consulta podem ser anexadas por todos os tipos de pessoas. Este exemplo vem da minha conta do Google Reader e é adicionado ao link em que clico para ver a entrada do blog original:
?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+DilbertDailyStrip+(Dilbert+Daily+Strip)&utm_content=Google+Reader
Se esse feed RSS tivesse sido chamado de "The Casting Couch" e estivesse vinculado ao seu site, você me serviria com um 403. Como a palavra-chave "cast" apareceu na string de consulta, mesmo sendo um usuário legítimo, estou bloqueado.
Este padrão:
^(.*)//(.*)$
É provável que acabe correspondendo a alguém que você enviou para o seu site por conta própria:
RewriteCond %{HTTP_COOKIE} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
Significa que você nunca pode usar um apóstrofo ou um retorno de carro ou uma barra em qualquer um dos seus cookies.
TL; DR
Não faça isso. É uma má ideia.
Adicione segurança ao seu aplicativo e tente mod_ segurança .