понедельник, 14 января 2013 г.

MSSQL : Практика предотвращения SQL-injection

Безопасность данных – не место для халтуры

Атака вида SQL-injection продолжает оставаться одной из самых серьезных угроз для SQL Server. База данных может быть восприимчива к таким атакам, если она или приложение (в основном это веб-приложения) содержат код, который хакер может использовать для ввода дополнительной команды SQL в одном из полей ввода приложения. Затем приложение подставляет модифицированный код в базу данных, в результате хакер может получить доступ к конфиденциальной информации, изменению данных или объектов базы данных, и запуску административных операций в базе данных или, в некоторых случаях, по отношению к операционной системе.

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

Введение в SQL-injection

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

Рисунок 1. Ввод идентификатора пользователя в пользовательский интерфейс 

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

Теперь предположим, что хакер хочет проникнуть в систему для получения данных или нанести ущерб. Например, хакер может попытаться удалить все данные из таблицы аренды (предполагается, что хакер может получить имя таблицы через отдельный хак). Вместо предоставления простого идентификатора пользователя, хакер мог бы также добавить команду TRUNCATE TABLE, как показано на рисунке 2.

Рисунок 2. Ввод изгоев код в пользовательском интерфейсе

Обратите внимание, что значение, введенное в пользовательский интерфейс, теперь включает в себя точку с запятой, а затем команду TRUNCATE TABLE. Поскольку SQL Server поддерживает точку с запятой в качестве разделителя команд и поддерживает несколько команд в блоке, хакер может легко отправить эти команды в базу данных. В результате, таблица аренды будет удалена.

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

Практика предотвращения SQL-injection

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

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

Использование хранимых процедур

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

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

Используйте динамический SQL только тогда, когда вы не можете избежать этого

Динамический SQL может значительно увеличить риск атаки SQL-injection, когда команда языка объединяется с пользовательскими данными. В некоторых случаях, однако, не возможно избежать динамического SQL. Например, вы можете определить хранимую процедуру, которая создает логин в базе данных, где логин передается в качестве параметра. Проблема в том, что заявление CREATE LOGIN не принимает значение переменной для имени, таким образом вы вынуждены построить вашу команду динамически и при этом пройти проверку синтаксиса ядром базы данных.

Один из способов помочь смягчить риски, связанные с динамическим SQL – корректно экранировать пользовательский ввод. Экранированию пользовательских значений помогают специальные безвредные символы, которые могут быть переданы на вход, (такие как скобки или одинарные кавычки). При использовании с другими элементами языка, эти символы, при использовании с другими элементами языка могут представлять угрозу для базы данных, когда объединяются в статической части SQL запроса. Чтобы избежать этих символов, используйте функции QUOTENAME или REPLACE по мере необходимости для обработки идентификаторов и строковых значений. При использовании какой-либо функции, убедитесь, что правильно рассчитали длину буфера для использования экранирующих символов, иначе вы подставите себя для атаки через усечение, (один из типов атаки SQL-injection, который использует усечение для инъекции вредоносного кода).

Другим способом предотвращения SQL-injection является использование системной хранимой процедуры sp_executesql, вместо оператора EXECUTE, для выполнения динамических запросов. С помощью хранимой процедуры sp_executesql, у вас есть способ использовать параметризацию динамического запроса, так что с данные остаются отдельно от команд языка. Но убедитесь, что правильно используете хранимую процедуру, не используйте ее в качестве простой замены EXECUTE. Вы должны включить параметры в определение команды при его создании и когда вы вызываете хранимую процедуру sp_executesql.

Используйте принцип наименьших привилегий при предоставлении доступа к базам данных

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

Даже внутри хранимых процедур, вы должны следовать стратегии минимального доступа. Например, если вы используете оператор EXECUTE AS, для запуска SQL запросов в процедуре, используйте учетную запись с минимальными привилегиями. Если высокопривилегированная операция должна быть выполнена, создайте хранимые процедуры для выполнения этой операции и подпишите хранимые процедуры с помощью сертификата. Цель состоит в том, чтобы гарантировать, что даже если злоумышленник обнаружит дыру в безопасности приложения, он мало что мог сделать. Приложение, имеющее доступ к БД, всегда должно быть ограничено низким уровнем привилегий учетной записи, имеющей минимальные права для выполнения запросов, выполняемых в базе данных.

Использование тестирования и мониторинга для защиты от SQL-инъекций

Независимо от того, насколько тщательны вы были в защите от атак SQL-injection, вы все равно должны запускать код базы данных через необходимые проверки, чтобы убедиться – это безопасно. Начните с проверок кода, которые специально проверяют код его на восприимчивость к SQL-injection, таких как неправильное использование динамического SQL. Отсюда вы можете перейти к фазе проверки качества. В дополнение к любому нормальному тестированию и проверки процессов, которые будут выполняться в базе данных, вместе с тем поддерживаемый код должен быть подвергнут попытке SQL-injection, чтобы попробовать найти уязвимости. Процесс тестирования должен включать все уровни SQL-injection, в том числе попытку усечения данных. Наконец, когда база данных используется, лог-файлы и другие устройства слежения должны быть использованы для мониторинга баз данных для любых признаков SQL-injection.

Защита от атак SQL инъекции

Принципы, предложенные выше, только затрагивают основные темы, но они должны направить вас в правильном направлении. Учитывая распространение мобильных приложений и растущую потребность синхронизировать данные между несколькими устройствами, необходимо проявлять бдительность больше, чем когда-либо. Даже одна уязвимость поставит вашу базу в зону риска, а безопасность данных – не место для халтуры. Разработчики баз данных и разработчики приложений должны работать вместе, чтобы избежать таких уязвимостей. Атаки SQL-injection могут быть предотвращены, но только если вы предпримете необходимые шаги для защиты вашей системы.

ОТДЫХ : Беларусь, Орша

29-го числа мы были в Беларуси, тут нами была намечена первая остановка, в г. Орша.
Я конечно понимаю, что описывая Беларусь, буду не объективен, особенно учитывая тот факт что это первая поездка за границу на автомобиле, но первое впечатление эта страна производит положительное.
Чистые и широкие улицы, ухоженные (по крайней мере покрашенные) дома.
Люди на улицах улыбаются.

Что еще понравилось, так это развитие малоэтажного строительства.
Уже на въезде в город можно увидеть явный новострой, 3-х этажные дома, с 2-мя или 3-мя подъездами.
При этом дома отстоят друг от друга достаточно далеко, что чуствуется пространство между ними.
Тут мне как антипод вспоминается московская и не только московская точечная застройка. Когда башню ставят в вашем дворе, загораживая при этом как вид из окна, так и уничтожая двор.

В общем о Беларусии у меня только положительные впечатления.