Будут ли эти шаблоны регулярных выражений улавливать все необходимые инъекции SQL?

Question

Мы изменили наши правила брандмауэра (Regex) к следующим:

Name 
Type 
Context 
Severity 
Pattern 

CS:select_into 
signature 
http-url 
critical 
.*\[select\]\s+.*\[into\].* 

CS:select_from 
signature 
http-url 
critical 
.*\[select\]\s+.*\[from\].* 

CS:insert_into 
signature 
http-url 
critical 
.*\[insert\]\s+.*\[into\].* 

CS:drop_database 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[database\].* 

CS:drop_table 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[table\].* 

CS:delete_from 
signature 
http-url 
critical 
.*\[delete\]\s+.*\[from\].* 

CS:drop_view 
signature 
http-url 
critical 
.*\[drop\]\s+.*\[view\].* 

CS:exec 
signature 
http-url 
critical 
.*\[exec\].*(%28|\().*(%29|\)).* 

CS:update_set 
signature 
http-url 
critical 
.*\[update\](%20|\+)(%20|\+|.)*\[set\].* 

Будет ли этот блок всех попыток инъекции SQL? Например, можно ли опустить представление, используя несколько пробелов?

Answer 1

Черный список - неправильный подход. Всегда будут вещи, о которых вы не думали, о которых подумает злоумышленник.

Какой язык программирования/база данных вы используете? Все они имеют методы передачи параметров в операторы SQL. Например:

String userName = .... ; // from your GET or POST parameter 
String sql = "SELECT id FROM user where user_name=?"; 
ResultSet rs = executeSql(sql, userName); 

См http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements

Answer 2

Попытка предотвратить SQL-инъекции, отфильтровывая определенные слова не будет работать - там всегда будет то, что вы пропустите и будет потреблять, чтобы попытаться найти все самое время покрывать.

Вы должны посмотреть на вещи, например, как вы запрашиваете базу данных - если вы строите SQL на лету и объединяете значения с клиентом непосредственно в оператор, то это будет важная область, на которую нужно сосредоточиться - переключиться на используя параметризованные SQL/хранимые процедуры. Хранимые процедуры также предоставят вам дополнительный уровень безопасности, поскольку вы можете предоставить разрешения для их выполнения, не предоставляя прямых прав на базовые таблицы.

Answer 3

Нельзя использовать регулярное выражение для фильтрации входных данных.

Вы должны отфильтровать свой ввод один за другим, прежде чем передавать их на сервер sql.

Если вы вставляете строку (или что-либо, что находится между апострофами в инструкции sql), вы должны использовать функцию escape-функции вашего SQL-сервера, которая предотвратит любые атаки там.

Если ваши данные представляют собой некоторый тип номера (целое число или поплавок), тогда вы должны проверить, действительно ли данные являются числом (вы не можете делать SQL-инъекцию без букв). Лучший способ сделать это зависит от языка программирования, который вы используете, но в основном проверки типа или принудительные типы.

Вы не должны вставлять какие-либо ненадежные (что-либо от пользователя ненадежные) строковые данные в sql statemen, где вы не можете размещать вокруг него апострофы, например, для таблицы или имени столбца.

Answer 4

Вы должны убедиться, что любой SQL-код выполняется только с учетной записи с ограниченными правами, у которой нет разрешений, кроме тех, которые явно требуются для приложения, а не попытки поймать все возможные перестановки нестабильного SQL.