Entity FrameWork защита от SQL инъекций

107

20 апреля 2021, 11:50

Начал изучать Entity FrameWork под .Net MVC, реализую DB First-то бишь есть готовая база Mysql и с помощью EF создаю сущности DBContext и т.д.(таблицы в классы).

Возникают вопросы, как защититься от sql injections при запросах к базе? На подобии PDO в php , например, как сделать выборку с параметром WHERE, где значение, пришедшее с клиента по http запросу -будет экранированное!Нужно защититься от инъекций! Классический пример ;1=1 и т.д.

Answer 1

EF использует параметризированные запросы, что исключает инъекции через кривые значения параметров.

Основной путь появления SQL инъекций - это вписывание значений параметров прямо в тело запроса (классический 1=1) срабатывает так:

Вы получаете от клиента по HTTP значение (' OR 1=1 --)
В коде на бэке вы вписываете прямо в тело запроса и получаете там NAME = '' OR 1=1...
SQL разбирает запрос, видит в нем условие на Name и проверку 1=1, выполняет код именно так, как написано в запросе - возвращает все строки злоумышленнику.

В SQL Server этот путь чинится параметризацией запросов. В тексте запроса передается только имя параметра, а не его значение (WHERE Name = @Name). Сами значения параметров передаются отдельно, и ни в какой момент в текст запроса не вписываются. Ни в сыром виде, ни в экранированном.

SQL Server составляет план выполнения на основе именно текста запроса. Вне зависимости от того, что будет передано ему в качестве параметр @Name - он будет фильтровать по колонке Name. 1=1 никак не может выпрыгнуть из значения параметра и влезть в текст запроса. И уже после составления плана ("отфильровать по Name"), в момент выполнения этого плана, при проходе по таблице будет использовано значение параметра, причем только как строка для поиска, а не как булево выражение.

Примерно так же ведет себя PDO в случае не-emulated prepare. Экранирование используется только в emulated режиме (не PHP-разработчик, не уверен, насколько он часто используется). Разница только в том, что в SQL Server prepare и параметризация разделены. Можно параметризировать не-prepared запросы, и наоборот.

EF использует внутри параметризированные запросы, так что протолкнуть через него SQL Injection не получится. Что-то может пойти не так только в случае, когда вы будете дергать через EF свои самописные процедуры SQL, в которых будете клеить динамический SQL из значений параметров. Но EF тут уже ни при чем.

Answer 2

На самом деле, если я конечно не ошибаюсь, ORM и в частности EF использует уже параметризованные запросы. Во всяком случае, если речь идёт о работе с объектной моделью сущностей.

Другое дело если Вы используете raw SQL запросы в том или ином виде. Но, использование SQL в открытом виде в EF нежелательно, т.к. противоречит самой сути подхода ORM. Да и с безопасностью это создаёт серьёзные проблемы.

Дополнительное чтение: Вопросы безопасности (Entity Framework).