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

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

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

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

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

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

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

Я не.

Вместо этого я использую параметризованные 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"]);

Это.

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

Я не. Цель уровня доступа к базе данных - предотвратить их, а не уровня сопоставления URL-адресов, чтобы их предсказать. Используйте подготовленные операторы или параметризованные запросы и не беспокойтесь о SQL-инъекции.

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

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

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

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

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

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

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

Что еще вы могли бы искать в URL-адресе в качестве первой линии защиты?

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

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

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

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

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