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

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

2 голосов
/ 22 октября 2010

Мы изменили наши правила брандмауэра (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? Например, возможно ли отбросить представление, используя несколько пробелов?

Ответы [ 4 ]

21 голосов
/ 22 октября 2010

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

Какой язык программирования / базу данных вы используете?Все они имеют методы передачи параметров в операторы 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

2 голосов
/ 22 октября 2010

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

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

0 голосов
/ 22 октября 2010

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

0 голосов
/ 22 октября 2010

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

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

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

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

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

...