SQL-инъекция или Server.HTMLEncode или оба? Классический ASP

Question

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

1. Подготовить операторы (параметризованные)
2. Хранимые процедуры
3. Выход из пользовательского ввода

Я выполнил пункт 1, подготавливая свои заявления, но теперь мне интересно, должен ли я также избежать пользовательского ввода.Это пустая трата времени, когда я готовлю заявления, или это удвоит мои шансы на предотвращение?

Answer 1

Обычно тратится время на то, чтобы избежать вашего ввода поверх использования параметризованных операторов. Если вы используете «драйвер» базы данных от поставщика базы данных, и вы только , используя параметризованный операторы без таких вещей, как конкатенация SQL String или попытка параметризации фактического синтаксиса SQL, вместо простого предоставления значений переменных, тогда вы уже настолько безопасны, насколько это возможно.

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

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

Answer 2

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

Однако существует вторичный источник внедрения SQL, где сам код SQL (обычно в SP) должен будет составлять некоторый SQL, который затемEXEC'd.Следовательно, все еще возможно быть уязвимым для внедрения, даже если ваш ASP-код всегда использует параметризованные запросы.Если вы можете быть уверены, что ни один из ваших SQL не сделает этого и никогда не будет делать , то вы достаточно защищены от SQL-инъекций.В зависимости от того, что вы делаете и какую версию SQL Server вы используете, бывают случаи, когда SQL-компоновка SQL неизбежна.

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

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

Server.HTMLEncode предотвращает другую форму внедрения.Без этого злоумышленник может внедрить HTML (включая JavaScript) в выходные данные вашего сайта.Например, представьте приложение-магазин, позволяющее покупателям просматривать продукты, которые другие покупатели могут прочитать.Злонамеренный «клиент» может внедрить некоторый HTML-код, который может позволить им собрать информацию о других реальных клиентах, которые читают их «обзор» популярного продукта.

Следовательно всегда используйте Server.HTMLEncode ввсе строковые данные, полученные из базы данных.

Answer 3

В те времена, когда мне приходилось делать классический ASP, я использовал оба метода 2 и 3. Мне больше понравилась производительность хранимых процедур, и это помогает предотвратить внедрение SQL. Я также использовал стандартный набор включений для фильтрации (экранирования) пользовательского ввода. Чтобы быть по-настоящему безопасным, не используйте классический ASP, но если вам нужно, я бы сделал все три.

Answer 4

Сначала о уколах вообще:

Оба последних 2 на самом деле не имеют ничего общего с инъекцией.
И первый не охватывает все возможные проблемы.

1. Подготовленные заявления в порядке, пока вам не придется иметь дело с identifiers.
2. Хранимая пробу также уязвима для инъекций. Это вообще не вариант.
3. «экранирование» «пользовательский ввод» - самый смешной из них.

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

Теперь к вашему вопросу.

Как вы можете заметить, HTMLEncode не содержит слова "SQL". Тогда можно предположить, что Server.HTMLEncode не имеет абсолютно никакого отношения к SQL-инъекциям.

Это больше похоже на другое предотвращение атак, называемое XSS. Здесь это кажется более подходящим действием и действительно должно использоваться при вводе данных ненадежным пользователем.

Итак, вы можете использовать Server.HTMLEncode вместе с подготовленными утверждениями. Но просто помните, что это совершенно другое предотвращение атак.

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