Способы обеспечения соблюдения подготовленных заявлений

Question

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

REVOKE DarnInlineDataStatements ON * TO xyz

Но так как это кажется маловероятным, есть ли, например, инструменты статического анализа кода для поиска этих вещей (до определенной степени надежности)? Или что-нибудь иначе вы бы порекомендовали?
edit : Подход мягких навыков «пожалуйста, не используйте их, есть (обычно) лучшие способы»), казалось, не работал слишком хорошо в прошлом. Поэтому я бы действительно предпочел что-то, что предотвращает подобные запросы. Не для преднамеренного взлома существующего кода, но для будущих проектов, некоторые решения "нет таких запросов" ;-)

Answer 1

Если вы перемещаете sql в хранимые процедуры, вы можете отключить разрешения SELECT, CREATE, ALTER, UPDATE, DELETE, DROP и т. Д. Для пользователя приложения, оставляя только доступ EXEC. Это предполагает SQL Server, но я уверен, что Oracle / MySQL и т. Д. Допускают аналогичные установки.

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

Answer 2

Вы можете просто найти в своей кодовой базе общие конструкции T-SQL, такие как SELECT, INSERT, UPDATE, DELETE и т. Д.

Если вы используете Visual Studio 2008 Team System, существует встроенное правило анализа кода, которое проверяет некоторые проблемы с SQL. В противном случае, есть бесплатный FxCop .

Answer 3

Если вы уже используете инструменты статического анализа кода, вы можете настроить его на использование определенных методов, например, в мире Java Connection.createStatement вместо Connection.prepareStatement.

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

Answer 4

Ваше приложение не должно отправлять код непосредственно на сервер базы данных, а отправляет его через промежуточный уровень. Он может легко анализировать все, что должно быть отправлено в БД, и накладывать на него некоторые ограничения. Например, заставить весь код SQL состоять из one и не более одного оператора, и либо отклонить его, либо выполнить первый оператор, только если их больше одного.

Основные атаки SQL-инъекций включают в себя такой код:

DECLARE @SQL VARCHAR(4000), @Table VARCHAR(50) 
SET @Table='Employees' -- Imagine this actually comes as a parameter from app
SET @SQL='SELECT * FROM '+@Table
EXEC(@SQL)

Злоумышленник может передать строку "systables"; UPDATE BankAccount SET Money = Money + 10000 WHERE AccountCode = 12345; DROP TABLE AuditTrails; " в БД - это имело бы катастрофические последствия.

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

Если вам понадобится для передачи более чем одного оператора SQL из вашего приложения, я бы сказал, что вы делаете что-то неправильно, и должен инкапсулировать эту логику в хранимой процедуре или минимум на самом среднем уровне. 1014 *

Answer 5

Надеемся, что найти все непараметрические запросы в вашем программном обеспечении достаточно просто. Большинство слоев доступа к базам данных, таких как PHP PDO или Perl DBI, имеют разные вызовы при подготовке запроса, чем когда они просто выполняют SQL. Выяснение, что это за звонки, и поиск по коду помогут вам хорошо начать. Если вы используете Linux, grep - ваш друг.

Оттуда их исправить будет достаточно просто (надеюсь). Я не знаю масштаб проекта, но, возможно, вам следует разместить запросы в одном месте или разработать какой-либо слой на основе общего шаблона, такого как Active Record / DataMapper / Table Row Gateway.

Я не думаю, что есть хороший способ автоматически применять его. Возможно, вам просто нужно пообщаться со своими коллегами. Встроенный SQL это плохо. Конец истории. Если вы лидер, я думаю, мандат будет в порядке.