Как Вы проверяете свой URL на Атаки с использованием кода на SQL?

Это.

править: Шаблоны MSDN и Методы ведут на предотвращении нападений инжекции 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"]);

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

Существует несколько различных способов сделать Атаку с использованием кода на SQL или через строку запроса или через поле формы. Лучшая вещь сделать состоит в том, чтобы санировать Ваш вход и гарантировать, что Вы только принимаете допустимые данные вместо того, чтобы пытаться защитить и заблокировать вещи, которые могли бы быть плохими.

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

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

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

• Каждая база данных имеет свои собственные расширения SQL. Необходимо было бы понять синтаксис глубоко и блок возможные нападения для различных типов запроса. Вы понимаете правила для взаимодействий между комментариями, вышел из символов, кавычек, и т.д. для Вашей базы данных?Наверное, нет.
• Поиск фиксированных строк хрупок. В Вашем примере Вы блокируетесь cast(0x, но что, если взломщик использует CAST (0x? Вы могли реализовать своего рода предварительный синтаксический анализатор для строк запроса, но он должен будет проанализировать нетривиальную часть SQL. SQL известно трудно проанализировать.
• Это измазывает отправку URL, представление и слои базы данных. Ваш диспетчер URL должен будет знать, который используют представления SELECT, UPDATE, и т.д. и должен будет знать, какая база данных используется.
• Это требует активного обновления сканера URL. Каждый раз новая инжекция обнаружена - и верьте мне, будут многие - необходимо будет обновить ее. Напротив, использование надлежащих запросов пассивно и будет работать без дальнейших забот с Вашей стороны.
• Необходимо будет быть осторожными что сканер никогда блоки законные URL. Возможно, Ваши клиенты никогда не будут создавать пользователя, названного "бросок (0x", но после того, как Ваш сканер станет достаточно сложным, "Fred O'Connor" инициирует "незавершенную одинарную кавычку" проверка?
• Как упомянуто @chs, существует больше способов получить данные в приложение, чем строка запроса. Вы готовы протестировать каждое представление, которое может быть POSTредактор к? Каждое представление формы и поле базы данных?

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

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

Предложенные решения до сих пор допустимы, важны и часть защиты против Атак с использованием кода на SQL. Вопрос об "ограничении входа" остается открытым: Что еще Вы могли искать в URL как первый оборонительный рубеж?

Что еще Вы могли искать в URL как первый оборонительный рубеж?

Ничего. Нет никакой защиты, которая будет найдена в сканировании URL для опасных строк.

Ничего. Нет никакой защиты, которая будет найдена в сканировании URL для опасных строк.

@John - можно ли уточнить?

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

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