Как вы проверяете свой URL для атак SQL-инъекций?

Question

Я видел несколько попыток атак с использованием SQL-инъекций на одном из моих веб-сайтов. Он представлен в виде строки запроса, которая включает ключевое слово cast и набор шестнадцатеричных символов, которые при «декодировании» представляют собой вставку баннерной рекламы в базу данных.

Мое решение состоит в том, чтобы сканировать полный URL-адрес (и параметры) и искать наличие «cast (0x») и, если оно существует, перенаправлять на статическую страницу.

Как вы проверяете свои URL-адреса для атак SQL-инъекций?

Answer 1

Не знаю.

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

Я знаю, что это новая концепция для разработчиков PHP и пользователей MySQL, но люди, использующие настоящие базы данных, делают это так годами.

Например (с использованием C #)

// Bad!
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'");

//Good! Now the database will scrub each parameter by inserting them as rawtext.
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = @LOL");
foo.Parameters.AddWithValue("@LOL",Request.QueryString["LOL"]);

Answer 2

Это.

edit: Руководство MSDN по шаблонам и практикам по предотвращению атак с помощью инъекций SQl. Неплохая отправная точка.

Answer 3

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

Answer 4

Я думаю, это зависит от того, на каком уровне вы хотите проверить / предотвратить SQL-инъекцию.

На верхнем уровне вы можете использовать URLScan или некоторые модули / фильтры Apache (кто-то мне здесь помог), чтобы проверить входящие URL-адреса самого веб-сервера и немедленно отбрасывать / игнорировать запросы, соответствующие определенному шаблону.

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

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

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

Это больше похоже на то, что вы хотите знать?

Answer 5

<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>

Answer 6

Что я не понимаю, так это то, что завершение запроса, как только SQL-инъекция обнаружена в URL, не будет частью защиты?

(Я не утверждаю, что это будет полное решение - только часть защиты.)

• Каждая база данных имеет свои собственные расширения для SQL. Вы должны глубоко понимать синтаксис и блокировать возможные атаки для различных типов запросов. Понимаете ли вы правила взаимодействия между комментариями, экранированными символами, цитатами и т. Д. Для вашей базы данных? Вероятно, нет.
• Поиск фиксированных строк хрупок. В вашем примере вы блокируете cast(0x, но что если злоумышленник использует CAST (0x? Вы могли бы реализовать какой-то предварительный анализатор для строк запроса, но он должен был бы анализировать нетривиальную часть SQL. Общеизвестно, что SQL трудно анализировать.
• Он запутывает уровни отправки, просмотра и базы данных. Ваш диспетчер URL должен знать, какие представления используют SELECT, UPDATE и т. Д., И должен знать, какая база данных используется.
• Требуется активное обновление сканера URL. Каждый раз, когда обнаруживается новая инъекция - и поверьте мне, будет много - вам придется ее обновлять. Напротив, использование правильных запросов пассивно и будет работать без каких-либо дополнительных забот с вашей стороны.
• Вы должны быть осторожны, чтобы сканер никогда не блокировал допустимые URL-адреса. Возможно, ваши клиенты никогда не создадут пользователя с именем «cast (0x»), но после того, как ваш сканер станет достаточно сложным, «Фред О'Коннор» вызовет проверку «не определенная одинарная кавычка»?
• Как уже упоминалось @chs, существует больше способов получить данные в приложение, чем строка запроса. Готовы ли вы проверить каждый вид, который может быть POST ed? Каждая форма отправки и поле базы данных?

Answer 7

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

Answer 8

Ничего. При проверке URL-адресов на наличие опасных строк не существует защиты.

@ Джон - можешь уточнить?

Что я не понимаю, так это то, что завершение запроса, как только SQL-инъекция обнаружена в URL, не является частью защиты?

(Я не утверждаю, что это будет полное решение - только часть защиты.)

Answer 9

Что еще можно найти в URL в качестве первой линии защиты?

Ничего. При проверке URL-адресов на наличие опасных строк не существует защиты.

Answer 10

Спасибо за ответы и ссылки. Кстати, я уже использовал параметризованные запросы, и поэтому атака была «попыткой», а не успешной. Я полностью согласен с вашими предложениями по параметризации запросов.

В опубликованной ссылке MSDN упоминается «ограничение ввода» как часть подхода, который является частью моей текущей стратегии. В нем также упоминается, что недостатком этого подхода является то, что вы можете пропустить некоторые опасные данные.

Предлагаемые решения на данный момент являются действительными, важными и являются частью защиты от атак с использованием SQL-инъекций. Вопрос об «ограничении ввода» остается открытым: что еще можно найти в URL в качестве первой линии защиты?