Обнаружить SQL-инъекцию

Question

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

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

Существует ли какой-либо расширенный код / ​​регулярное выражение / магия, который может определить, содержит ли этот текст фрагмент SQL-запроса вместо обычного безвредного текста?Я буду принимать любые ссылки, фрагменты кода на любом языке или даже коммерческое программное обеспечение, которое сделает это для меня.

Спасибо

Answer 1

Здесь нет серебряной пули.Инъекции SQL могут встречаться во многих скрытых формах и пытаться обнаружить их с помощью регулярных выражений или другой формы в брандмауэре, или приложение может защитить вас от самых простых форм внедрения SQL, но опытный хакер просто справится.Как уже отмечал AdaTheDev, автоматизированные инструменты для проверки вашего кода, такие как MS Code Analysis Tool, могут дать вам толчок, но опять-таки серебряной пули нет.Вам нужно будет пройти через все ваше заявление.

Когда это большая работа, вы должны составить план.Прежде всего, составьте руководство, в котором говорится, как можно смягчить атаки такого типа.Также постарайтесь разделить ваше приложение на части, от очень критических до менее критичных.Таким образом, вы сможете лучше оценить затраты на исправление ошибок и позволить руководству решить, сколько это может стоить и, следовательно, какой риск они готовы взять на себя.Части вашего приложения, к которым могут получить доступ неаутентифицированные пользователи, являются наиболее важными.Если каждый (в мире) может создать учетную запись в вашем приложении, все функции, к которым имеют доступ эти пользователи, крайне важны.Чем меньше население и чем больше вы доверяете этим пользователям, тем меньше риск.Возможно, вам удастся исправить эти детали позже.Но никогда не стоит недооценивать хорошего хакера.Возможно, он / она сможет скомпрометировать учетную запись пользователя с высокими привилегиями и начать тестировать возможности внедрения SQL с использованием этой учетной записи.

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

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

Я желаю вам удачи.

Answer 2

Чтобы действительно сделать это правильно, вам нужно просто разделить приложение и пройти через него по одному модулю / странице / классу / что угодно за раз.

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

UPDATE
На основании комментария я хотел бы добавить еще одну вещь:

Единственное, что может сделать инструмент, это сказать: посмотрите, вот некоторые неанизированные входные данные ... Что, скорее всего, будет примерно для каждого запроса в вашем приложении. Это означает, что у вас будет около 3000 файлов, которые нужно исправить.

В этот момент единственное, что вы можете сделать, это назначить день, например, пятницу, как Fix Sql Day. Разделите работу и попросите всех провести день (или даже пару часов), переписывая запросы на нескольких страницах.

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

Answer 3

Вы можете дать MS Code Analysis Tool вихрь, который (цитата):

CAT.NET - это инструмент анализа двоичного кода, который помогает идентифицировать распространенные варианты определенных преобладающихуязвимости, которые могут привести к распространенным векторам атак, таким как межсайтовый скриптинг (XSS), SQL-инъекция и XPath-инъекция.

Никогда не использовал его сам, но стоит попробовать.

Answer 4

Вам необходимо проверить, где переменные передаются в строки SQL.Для строковых значений вы должны заменить каждый экземпляр одинарной кавычки двойной кавычкой.Для нестроковых значений (тех, которые будут передаваться в SQL без кавычек), вы должны убедиться, что они строго типизированы.

Например, не передавайте что-то вроде "SELECT * FROM Users WHERE UserID = " + my_string_user_id.Вместо этого используйте код "SELECT * FROM Users WHERE UserID = " + userId_as_int.

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

Answer 5

Я приветствую вашу готовность окунуться и исправить ситуацию, а не просто пожать плечами и сказать: «Э-э ... никто не будет атаковать наш сайт в любом случае».

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

Простая попытка обнаружить такие шаблоны может привести к ложноположительным результатам «атаки»;Может быть, кто-то пытается найти john's car, даже не зная, что одиночная кавычка может быть «плохой».И, возможно, им действительно нужно искать это.Или что у тебя ...