Temos segurança em nosso firewall para impedir que o SQL-Injection destrua qualquer conteúdo:
Name
Type
Context
Severity
Pattern
Configure
CS:select_into
signature
http-url
critical
.*\[select\].*\[into\].*
Edit
Remove
CS:select_from
signature
http-url
critical
.*\[select\].*\[from\].*
Edit
Remove
CS:insert_into
signature
http-url
critical
.*\[insert\].*\[into\].*
Edit
Remove
CS:drop_database
signature
http-url
critical
.*\[drop\].*\[database\].*
Edit
Remove
CS:drop_table
signature
http-url
critical
.*\[drop\].*\[table\].*
Edit
Remove
CS:delete_from
signature
http-url
critical
.*\[delete\].*\[from\].*
Edit
Remove
CS:drop_view
signature
http-url
critical
.*\[drop\].*\[view\].*
Edit
Remove
CS:exec
signature
http-url
critical
.*\[exec\].*(%28|\().*(%29|\)).*
Edit
Remove
CS:update_set
signature
http-url
critical
.*\[update\](%20|\+)(%20|\+|.)*\[set\].*
Edit
Remove
Como podemos ajustar isso para que, em um dos nossos próprios URLs, seja possível carregar os seguintes arquivos?
FileDropAreaIconsAndDescriptionsView.css
FileDropAreaIconsHorizontalView.css
FileDropAreaIconsView.css
FileDropAreaTableView.css
Os arquivos contêm as palavras "soltar" e "visualizar", o que faz com que a URL esteja em conformidade com as regras a serem bloqueadas. Como podemos ignorar a expressão regular de uma forma que, neste caso, com os nomes de arquivo mencionados acima, passará esta regex e, portanto, não será bloqueada?
Esta é quase certamente a abordagem errada para se proteger de ataques de injeção de SQL. Se você simplesmente olhar para o código do seu aplicativo, e escrever mecanismos de proteção nas rotinas de acesso ao banco de dados, ou melhor ainda, use uma Camada de Abstração do Banco de Dados (uma que já tenha proteção de injeção), e você não terá que se preocupar com essa invasão.
Sério, você está fazendo errado.