Где уязвимы ORM для SQL-инъекций?
при использовании ORM (Entity Framework, LINQ to SQL, NHibernate ...), являются ли атаки SQL-инъекций смягченными по дизайну?
Если нет, где я должен делать дополнительную проверку / очистку, чтобы предотвратить уязвимость?
4 ответов
большинство, если не все, основные ORMs используют параметризованный SQL, который защитит вас от прямой атаки SQL-инъекции. Однако параметризованный SQL на уровне приложения не защитит вас от скрытых атак SQL-инъекций. Они возникают, когда что-то вниз по строке, кроме ORM, непосредственно объединяет пользовательский ввод в инструкции SQL (например, хранимая процедура пакетного запуска, которая объединяет пользовательский ввод для создания непараметризованного динамического запроса). Обратите внимание, что это вообще не проблема ORM, но я подумал, что я хотел бы указать, что параметризованный SQL защищает вас только от инъекций, если он используется везде, а не только в ORM.
ORMs обычно используют много динамического SQL, что небезопасно, поскольку дает пользователям приложений и/или учетных записей служб возможность выполнять специальные SQL-запросы. Правильное решение заключается в том, чтобы только программисты и администраторы БД имели DataReader/DataWriter и все программы, которые касаются базы данных, не использовали ничего, кроме параметризованных хранимых процедур, всегда без доступа к DataReader/DataWriter, связанного с программой. Они могут получить доступ только к SPs, я говорю, что они могут. Только DB Администраторы и программисты должны иметь возможность выполнять специальные SQL-запросы.
ORMs предназначены для обеспечения безопасности, в основных понятиях. Большую часть времени вам не придется беспокоиться об этом, но если вы думаете, что может грозить реальный взлом, вы должны сделать некоторые пользовательские настройки.
для простых приложений, простой SQL-инъекции вы будете покрывать. Никакое тело (серьезно, никакое тело никогда) не даст вам серебряную пулю в вопросах безопасности и SQL-инъекции. Это мой совет.