Кто-то недавно сказал мне, что им не нужно беспокоиться о SQL-инъекции, потому что они используют ORM.

О, парень.

ORM не предотвращают автоматическое внедрение SQL-кода

Инструменты объектно-реляционного сопоставления (ORM) позволяют разработчикам легко получать доступ к уровню данных приложения без необходимости написания большого количества избыточного кода.

Большинство ORM безопасно параметризуют определенные типы запросов. В следующих примерах используются Entity Framework и SQL Server, но эти примеры должны применяться к большинству других основных ORM и СУБД).

Наш запрос LINQ, упрощающий доступ к нашему уровню данных:

И затем SQL-запрос, сгенерированный нашей ORM.

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

Но хотя ORM могут предотвратить некоторые попытки внедрения SQL, нет гарантии, что они предотвратят все попытки внедрения.

Ниже приведены примеры того, когда ORM могут позволить успешные атаки с использованием инъекций.

Программно собранный SQL

ORM часто предоставляют разработчикам возможность сопоставлять результаты специальных запросов SQL с моделями. Специальные запросы означают потенциальные уязвимости для инъекций.

Учтите следующее:

Entity Framework или любая ORM в этом отношении не сможет распознать параметр, добавленный непосредственно в строку запроса.

Теперь, надеюсь, у разработчика есть действительно сильная проверка ввода для параметра «username», но факт остается фактом: этот запрос является инъекционным, и ORM с радостью выполнит его.

Хранимые процедуры

Существует ли логика, необходимая в вашем приложении, в виде хранимой процедуры?

Отлично! Давайте перейдем к DRY (не повторяйтесь) и вызовем нашу процедуру прямо из ORM:

Итак, в этом примере ORM и разработчик сделали все правильно. Так где же уязвимость инъекций?

Теперь позвольте мне прояснить: эта уязвимость внедрения не является ошибкой ORM.

Однако виноват разработчик, если он слепо использует процедуру, не зная, что она делает. Администратор базы данных также виноват, если он предоставил инъекционную процедуру, предполагая, что разработчик очистит любые входные значения в приложении.

Безопасность - это сложно. Все должны работать вместе и нести ответственность за то, чтобы делать все, что в их силах, для защиты своих приложений.

ORM-инъекция

Технически это не пример SQL-инъекции.

Но именно поэтому в заголовке этого поста написано «2,5» вместо «3».

В этом примере я использую динамический LINQ для доступа к своим данным:

Если мы передадим значение \" OR 1 == 1 OR UserName==\", ORM преобразует его в следующий запрос:

Инъекция принимает разные формы и не исходит только от SQL. Чтобы предотвратить нарушения безопасности, важно следовать передовым методикам и инструментам на всех языках.

Хотите узнать больше?

Если вам интересно узнать больше о том, как защитить себя от SQL-инъекций, обязательно посмотрите мою онлайн-сессию в GroupBy в 9 утра по восточному времени 16 марта 2018 года.

Первоначально опубликовано на сайте bertwagner.com 6 марта 2018 г.