Способы и приемы защиты от SQL-инъекций

Question

У меня есть приложение WinForms (Framework для разработки простых приложений), написанное на C #.Позже мой фреймворк будет использоваться для разработки приложений для форм win.Другие разработчики часто являются новичками и иногда не используют параметры - они пишут прямой SQL в коде.Итак, сначала мне нужно как-то сделать защиту в моих базовых классах фреймворка в C #.Решите это, один разработчик предложил мне использовать ORM, такой как NHibernate, который позаботится об этой проблеме для вас (и вам не придется писать операторы SQL большую часть времени).Поэтому я хочу спросить, есть ли какие-то общие альтернативы (другие способы и методы), когда я хочу получить защиту от SQL-инъекций. Некоторые ссылки или примеры были бы очень хорошими.

Answer 1

Согласитесь с Aaronaught, рамки не полностью исключают такую ​​возможность.Я бы никогда не заменил строгую проверку на уровне данных.Также предоставьте уровень абстракции для доступа к данным, который вы открываете как API, а не позволяйте разработчикам напрямую подключаться к базе данных.

Answer 2

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

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

Answer 3

Я не понимаю, каким образом можно защитить любую библиотеку на основе SQL от злоупотребления developer без ущерба для ее функциональности (т. Е. Никогда не предоставлять прямой доступ к базе данных).

Даже с NHibernate или Linq to SQL можно обойти слои отображения и напрямую написать оператор SQL.

Лично я думаю, что лучшим вариантом было бы написать БОЛЬШОЙ ЖИРНЫЙ ТЕКСТ , что люди, которые используют вашу библиотеку, должны ПАРАМЕТРИРОВАТЬ ИХ ЗАПРОСЫ . Если это не удастся, вы можете попытаться выполнить некоторую неуклюжую очистку входных данных, но это, честно говоря, хрупкий второсортный взлом.

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

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

Answer 4

Безопасность - это обычно процесс, а не продукт или API. Это также развивающийся процесс, который мы должны адаптировать или взломать.

Тяжелый подход: Вы можете заставить всех писать хранимые процедуры, а не разрешать прямой доступ к таблице из учетных записей, с которыми разрешено общаться база данных. (GRANT EXECUTE ON и т. Д.)

Тогда вам нужно убедиться, что никто не пишет какие-то необычные хранимые процедуры. которые принимают SQL-запрос в качестве параметра и оценивают его динамически.

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