У нас есть защита в нашем брандмауэре, чтобы SQL-инъекция не уничтожила любой наш контент:
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
Как мы можем настроить это так, чтобы с одного из наших собственных URL-адресов можно было загружать следующие файлы?
FileDropAreaIconsAndDescriptionsView.css
FileDropAreaIconsHorizontalView.css
FileDropAreaIconsView.css
FileDropAreaTableView.css
Файлы De содержат слова «drop» и «view», и это заставляет URL-адрес соответствовать правилам, которые должны быть заблокированы. Как мы можем изменить регулярное выражение таким образом, чтобы в этом случае указанные выше имена файлов передавали это регулярное выражение и, следовательно, не блокировались?
Это почти наверняка неправильный подход к защите от атак SQL Injection. Если вы просто посмотрите на код своего приложения и запишете механизмы защиты в подпрограммы доступа к базе данных, или еще лучше, используйте уровень абстракции базы данных (тот, который уже имеет защиту от инъекций), и вам не придется беспокоиться об этом дерьмовом взломе.
Серьезно, вы делаете это неправильно.