1. Введение

За прошедшие несколько лет, атаки направленные на различные Web приложения требовали особенного внимания со стороны защитного персонала. Все это происходит из-за того, что насколько бы сильной не была ваша межсетевая защита или насколько прилежно бы вы не залатывали "дыры" в существующих программах, все равно может случиться, что разработчики ПО не достаточно хорошо защитили свои программы, и злоумышленники могут использовать для взлома 80 порт. Существует два наиболее часто используемых метода для нападений: SQL инъекция [1] и межсайтовый скриптниг [2]. SQL инъекция относится к методике вставки мета-симолов и SQL команд в поля ввода на Web страницах, что приводит изменению выполнения конечных SQL запросов. Такие нападения в основном направлены на Web-сервера. Принцип работы межсайтового скриптинга основан на внедрении злонамеренного кода в URL строку, что приводит к выполнению такого кода на машине жертвы, при нажатии пользователем на URL ссылке.

В данной статье будут обсуждены методы обнаружения SQL инъекций и атак межсайтового скриптинга (CSS атак), при нападении на вашу сеть. Ранее были достачно хорошо осуждены методы предотвращения этих видов атак, однако плохо описывались методы обнаружения нападений. В наших примерах мы будем использовать программу IDS Snort [3] и составим регулярные выражения, основанные на правилах для обнаружения таких видов атак. Кстати, заданные по умолчанию значения наборов правил Snort действительно содержит сигнатуры для обнаружения сценариев межсайтового скриптига, но их можно очень легко обойти, используя, например, шестнадцатиричные значения символов типа %3C%73%63%72%69%70%74%3E вместо <script>.

Было написано огромное, граничащее с паранойей, количество правил для обнаружения подобных атак. Если Вы хотите обнаружить любой вариант SQL атаки, то необходимо исключить возможность ввода любого из метасимволов SQL типа одинарной кавычки('), точки с запятой ( или двойного тире (--). Точно такой же параноидальный способ обнаружении CSS атак заключается в нахождении угловых скобок (<>), указывающих на HTML-тэг. Но при таких условиях возникает вероятность того, что большое количество правильных выражений, будут распознаны как попытки нападений. Чтобы избежать этого, необходимо, чтобы условия проверки были более точными и при этом не приводили к неправильной идентификации.

Каждое из таких условий может использоваться как самостоятельно, так и с командами Snort сигнатур, используя ключевое слово pcre [4]. Эти сигнатуры могут также использовать с утилитами типа grep для проверки файлов регистрации на Web серверах. Но такой способ может использоваться, только если приложения используют GET запросы, т.к. данные о POST запросах не сохраняются в файлах регистрации.

2. Регулярные выражения для SQL инъекций.

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

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

2.1 Регулярное выражение для определения SQL метасимволов

/(%27)|(')|(--)|(%23)|(#)/ix </TD< tr>

Пояснения:

Для начала мы обнаруживаем шестнадцатеричный эквивалент одинарной кавычки или непосредственно саму кавычку, а также присутствие двойного тире. Это символы MS SQL Сервер и Oracle, обозначающие начало комментария (т.е. все что следует за этими символами - игнорируется). Дополнительно, в случае использования MySQL, Вы должны проверить присутствие '*' или его шестнадцатеричного эквивалента. Обратите внимание на то, что мы не должны проверять шестнадцатеричный эквивалент двойного тире, т.к. он не является метасимволом HTML и не будет закодирован браузером. Также, если злоумышленник попытается вручную изменить двойное тире на его шестнадцатеричный эквивалент (используя прокси типа Achilles), то в атаке с помощью SQL инъекции произойдет сбой.

Указанное выше выражение необходимо следующим образом добавить к новому правилу Snort:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid";
flow:to_server,established;uricontent:".pl";pcre:"/(%27)|(')|(--)|(%23)|(#)/i";
classtype:Web-application-attack; sid:9099; rev:5 </TD< tr>

В нашем случае, ключевое слово uricontent имеет значение ".pl", т.к. в среде, в которой мы проводим наши испытания, CGI сценарии написаны на Perl. В зависимости от вашего приложения это значение может быть ".php", или ".asp", или ".jsp", и т.д.

С помощью описанного выше выражения мы обнаруживаем присутствие двойного тире, т.к. бывают ситуации, когда SQL инъекция возможна даже без применения одинарной кавычки [6]. Примером может служить SQL запрос с предложением where, содержащим только числовые значения:

select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number

В этом случае, злоумышленник может выполнить дополнительный SQL запрос, выполнив ввод следующего выражения:

3; insert values into some_other_table

И наконец, pcre модификаторы 'i' и 'x' используются, соответственно, для игнорирования регистра символов и пробелов(или знаков табуляции).

Описанная выше сигнатура может быть дополнена для обнаружения знака "точка с запятой". Однако точка с запятой может вполне нормально быть частью HTTP трафика. Для уменьшения вероятности неправильной идентификации, такая сигнатура может быть модифицирована, чтобы сперва обнаруживать символ "=". Ввод данных пользователем обычно происходит как POST или GET запрос, в котором входные поля будут выглядеть следующим образом:

username=some_user_supplied_value&password=some_user_supplied_value

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

2.2 Модифицированные регулярные выражения для обнаружения SQL метасимволов.

/((%3D)|(=))[^n]*((%27)|(')|(--)|(%3B)|()/i </TD< tr>

Пояснения:

Такая сигнатура сначала находит символ "=" или его шестнадцатеричный эквивалент (%3D). После этого, игнорируя разделители строк и пробелы, производиться поиск вхождений одинарной кавычки, двойного тире или точки с запятой.

Обычно попытки SQL инъекций сводятся к использованию одинарной кавычки для управления первоначальным запросом. В большинстве примеров, приводимых в статьях посвященных этому типу нападений, используется строка 1'or '1' = '1. Однако от обнаружения этой строки можно легко уклониться, использую значение типа 1'or2> 1--. Таким образом, единственной постоянной частью таких выражений остается символьное значение, сопровождаемое одинарной кавычкой, с последующим за ней словом "or".

2.3 Регулярное выражение для типичных SQL инъекций

/w*((%27)|('))((%6F)|o|(%4F))((%72)|r|(%52))/ix </TD< tr>

Пояснения:

w* - ноль или другие алфавитно-цифровые символы или символы подчеркивания

( %27) | ' - одинарная кавычка или её шестнадцатеричный эквивалент

( %6F) |o | ( % 4F)) (( %72) |r | ( % 52) - слово 'or' в различных комбинациях верхнего и нижнего регистров и их шестнадцатеричные эквиваленты.

Часто, проведение SQL инъекций при атаках на различные базы данных сопровождается использованием ключевого слова "union". При использовании описанных ранее регулярных выражений мы можем лишь определить наличие одинарной кавычки или других метасимволов SQL. Но далее мы будем модифицировать наши регулярные выражения для определения одинарной кавычки и ключевого слова "union". То же самое можно сделать и для других ключевых слов SQL типа 'select', 'insert', 'update', 'delete' и т.д.

2.4 Регулярное выражения для определения SQL инъекции с использованием ключевого слова “union”.

/((%27)|('))union/ix
(%27)|(') – одинарная кавычка и её шестнадцатеричный эквивалент

union – ключевое слово «union»

Подобные выражения могут быть написаны и для других SQL запросов типа > select, insert, update, delete, drop и т.д.

В случае если хакер обнаружил, что WEB приложение уязвимо к SQL инъекции, он начнет эксплуатировать эту уязвимость. Если нужная база данных храниться на MS SQL сервере, то хакер, скорее всего, попробует выполнить одну их многих опасных сохраненных или расширенных сохраненных процедур. Названия таких процедур начинаются, соответственно, с 'sp' или 'xp'. Как правило, он попытался бы выполнить расширенную процедуру 'xp_cmdshell', позволяющую выполнять через SQL сервер команды оболочки Windows. Права доступа с которыми выполниться эта процедура будут такие же как и у учетной записи с которой запущен SQL сервер (обычно Local System). Дополнительно, злоумышленник попытается внести изменения в реестр с помощью использования процедур xp_regread, xp_regwrite, и т.д.

2.5 Регулярное выражение для определения SQL инъекции на MS SQL сервере.

/exec(s|+)+(s|x)pw+/ix </TD< tr>

Пояснения:
exec – ключевое слово необходимое для запуска сохраненной или расширенной процедуры

(s|+)+ - один или несколько пробелов или их эквиваленты закодированные HTTP

(s|x)p – символы 'sp' или 'xp' необходимые для идентификации сохраненной или расширенной процедуры, соответственно

w+ - один или несколько алфавитно-цифровых символов или символов подчеркивания, необходимых для завершения написания имени процедуры.

3. Регулярные выражения для определения атак межсайтового скриптинга (CSS атак)

При выполнении CSS атаки или при испытании сайта на уязвимость к таким атакам, хакер для начала может создать простой форматирующий HTML тэг типа <b> для полужирного, <i> для курсива или <u> для подчеркивания. Также можно использовать тривиальный тэг сценария типа <script>alert("OK")</script>. Такие сценарии описаны в большинстве руководств как самые простые примеры определения уязвимости сайта к CSS атакам. Такие попытки можно очень легко обнаружить. Однако более продвинутый хакер может маскировать такие строки введя их шестнадцатеричные эквиваленты. Так, к примеру, тэг <script> был бы представлен в виде %3C%73%63%72%69%70%74%3E. С другой стороны злоумышленник может использовать программы типа Achilles и изменять автоматическое преобразование браузером специальных символов типа < to %3C and > в %3E.

Ниже представлено регулярное выражение, определяющее атаки, содержащие открывающие и закрывающие HTML тэги <> с любым текстом внутри. Такое выражение будет отлавливать попытки использования <b>, <u> или <script>. Также мы должны будем проверить наличие угловых скобок и их шестнадцатеричных эквивалентов или (%3C|<). Для обнаружения шестнадцатеричных эквивалентов, необходимо определить наличие в строке чисел и символов %, другими словами использование [a-z0-9 %]. При таком подходе возможна неправильная идентификация, но в большинстве случаев атака будет обнаружена.

3.1 Регулярное выражение для примитивной CSS атаки

/((%3C)|)/ix </TD< tr>

Пояснения:
((%3C)|) - проверяет наличие закрывающейся угловой скобки или её шестнадцатеричного эквивалента

Snort сигнатура

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"NII Cross-site scripting attempt"; flow:to_server,established; pcre:"/((%3C)|)/i";
classtype:Web-application-attack; sid:9000; rev:5 </TD< tr>

Существует еще один способ выполнения CSS атаки - использование <img src => методики. Заданную по умолчанию сигнатуру Snort можно легко обойти. Сигнатуру, представленную в пункте 3.2 обойти будет гораздо сложнее.

3.2 Регулярное выражение для определение CSS атаки с помощью
"<img src" /((%3C)|)/I </TD< tr>

Пояснения:
(%3C)|) закрывающаяся угловая скобка или её шестнадцатеричный эквивалент.

3.3 Параноидальное выражения для определения CSS атак.

/((%3C)|)/I </TD< tr>

Пояснения:

Такая сигнатура ищет открывающийся HTML тэг и его шестнадцатеричный эквивалент с последующими за ним символами, отличными от символа новой строки, а затем сопровождаемый закрывающейся угловой скобкой или её шестнадцатеричным эквивалентом. В зависимости от конфигурации вашего Web приложения, такое условие может привести к неправильной идентификации выражений, но зато гарантирует определение любого, что хотя бы отдаленно напоминает CSS атаку.

4. Заключение

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

5. Ссылки

1. SQL Injection http://www.spidynamics.com/papers/SQLIn … ePaper.pdf
2. Cross Site Scripting FAQ http://www.cgisecurity.com/articles/xss-faq.shtml
3. The Snort IDS http://www.snort.org/
4. Perl-compatible regular expressions (pcre) http://www.pcre.org/
5. Web application proxy, Achilles http://achilles.mavensecurity.com/
3. Advanced SQL Injection http://www.nextgenss.com/papers/advance … ection.pdf
7. Secure Programming HOWTO, David Wheeler http://www.dwheeler.com/
8. Threats and Countermeasures, MSDN, Microsoft http://msdn.microsoft.com/