1. Обзор
В последние два года экспертам по безопасности следует уделять больше внимания атакам на уровне сетевых приложений. Потому что независимо от того, насколько строги ваши правила брандмауэра или насколько усердно вы их исправляете, если разработчики ваших веб-приложений не будут следовать безопасному коду, злоумышленники проникнут в вашу систему через порт 80. Двумя основными методами атак, которые широко используются, являются атаки SQL-инъекция [ref1] и CSS [ref2]. SQL-инъекция относится к методу вставки метасимволов SQL (специальных символов, представляющих некоторые данные) и инструкций через область ввода Интернета для управления выполнением внутренних SQL-запросов. Эти атаки в основном нацелены на веб-серверы других организаций. CSS-атаки гарантируют запуск вредоносного кода Javascript на компьютере жертвы путем вставки тегов сценария в URL-адреса, а затем убеждения доверяющих им пользователей щелкнуть по ним. Эти атаки используют доверительные отношения между пользователем и сервером. Фактически сервер не обнаруживает ввод и вывод и, следовательно, не отклоняет код JavaScript.
В этой статье обсуждаются методы обнаружения уязвимостей SQL-инъекций и CSS-атак. В Интернете было много дискуссий об этих двух типах веб-атак, например, о том, как реализовать атаки, их влияние и как лучше подготовить и разработать программы для предотвращения этих атак. Однако недостаточно дискуссий о том, как обнаружить эти атаки. Мы используем популярную IDS Snort с открытым исходным кодом [ссылка 3] для формулирования регулярных выражений на основе правил обнаружения таких атак. Кстати, настройки правил Snort по умолчанию включают методы обнаружения CSS, но их можно легко избежать. Например, большинство из них используют шестнадцатеричную кодировку, например %3C%73%63%72%69%70% 74%3E вместо <script>, чтобы избежать обнаружения.
В зависимости от возможностей организации на уровне паранойи мы написали несколько правил для обнаружения одной и той же атаки. Если вы хотите обнаружить все возможные атаки SQL-инъекций, вам нужно просто обратить внимание на любые существующие метасимволы SQL, такие как одинарные кавычки, точки с запятой и двойные тире. Еще один крайний способ обнаружить CSS-атаки — просто следить за угловыми скобками в HTML-тегах. Но это позволит обнаружить множество ошибок. Чтобы этого избежать, правила необходимо модифицировать, чтобы сделать их обнаружение более точным, но при этом не избежать ошибок.
Используйте ключевое слово pcre (Perl-совместимые регулярные выражения) [ref4] в правилах Snort, и каждое правило можно применять с другими действиями правил или без них. Эти правила также могут использоваться общедоступным программным обеспечением, таким как grep (инструмент поиска документов), для просмотра журналов сетевого сервера. Однако вам следует быть осторожным, поскольку WEB-сервер будет записывать ввод пользователя в дневник только тогда, когда запрос отправлен как GET. Если запрос отправлен как POST, он не будет записан в дневнике.
2. Регулярные выражения для SQL-инъекций.
Когда вы выбираете регулярное выражение для атаки SQL-инъекцией, важно помнить, что злоумышленник может выполнить SQL-инъекцию, отправив форму или через поле Cookie. Ваша логика обнаружения ввода должна учитывать различные типы ввода, организованные пользователем (например, информацию о формах или файлах cookie). А если вы обнаружите много предупреждений, исходящих от правила, обратите внимание на одинарные кавычки или точки с запятой, поскольку эти символы могут быть допустимыми входными данными в файлах cookie, созданных вашим веб-приложением. Поэтому вам необходимо оценить каждое правило для вашего конкретного веб-приложения.
Как упоминалось ранее, при составлении подробного регулярного выражения для обнаружения атак SQL-инъекций следует обращать внимание на специальные метасимволы SQL, такие как одинарные кавычки (') и двойные знаки расширения (--), чтобы обнаружить эти символы и их значения. число шестнадцатеричных эквивалентов, применяются следующие регулярные выражения:
2.1 Регулярные выражения для обнаружения метасимволов SQL
/(%27)|(')|(--)|(%23)|(#)/ix
объяснение:
сначала мы проверяем шестнадцатеричный код эквивалента одинарной кавычки, саму одинарную кавычку или двойную кавычку. знак расширения. Это символы MS SQL Server или Oracle, указывающие на то, что последующие комментарии являются комментариями, а все последующие будут игнорироваться. Кроме того, если вы используете MySQL, вам необходимо обратить внимание на появление символа «#» и его шестнадцатеричного эквивалента. Обратите внимание, что нам не нужно проверять шестнадцатеричный эквивалент двойного тире, поскольку это не метасимвол HTML и не будет закодирован браузером. Кроме того, если злоумышленнику удастся вручную изменить двойное тире на его шестнадцатеричное значение %2D (используя прокси-сервер, такой как Achilles [ссылка 5]), SQL-инъекция завершится неудачно.
Новое правило Snort, добавленное к приведенному выше регулярному выражению, выглядит следующим образом:
alert tcp $EXTERNAL_NET Any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,installed;uricontent:".pl";pcre: "/ (%27)|(')|(--)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5;)
In эта статья В обсуждении значение ключевого слова uricontent — «.pl», поскольку в нашей тестовой среде программа CGI написана на Perl. Значение ключевого слова uricontent зависит от вашего конкретного приложения. Это значение может быть «.php», «.asp» или «.jsp» и т. д. С этой точки зрения мы не показываем соответствующие правила Snort, но приведем регулярные выражения, создающие эти правила. С помощью этих регулярных выражений вы можете легко создать множество правил Snort. В предыдущих регулярных выражениях мы обнаружили двойные тире, поскольку могут быть точки внедрения SQL, даже если нет одинарных кавычек [ссылка 6]. Например, запись SQL-запроса содержит только числовые значения, а именно:
выберите значение1, значение2, число_значение3 из базы данных.
где num_value3=some_user_supplied_number
. В этом случае злоумышленник может выполнить дополнительные запросы SQL. Демонстрация отправляет следующие входные данные:
3; вставить значения в some_other_table.
Наконец, модификаторы pcre 'i' и 'x' используются для сопоставления регистра и. игнорировать пустое пространство соответственно. Вышеупомянутые правила также можно дополнительно расширить для проверки наличия точек с запятой. Однако точка с запятой вполне может быть частью обычного ответа HTTP. Чтобы уменьшить эту ошибку и предотвратить нормальное появление одинарных кавычек и двойных знаков расширения, приведенные выше правила следует изменить, чтобы сначала обнаруживать наличие знаков =. Пользовательский ввод будет отвечать на запрос GET или POST. Обычно ввод осуществляется следующим образом:
username=some_user_supplied_value&password=some_user_supplied_value.
Таким образом, попытки SQL-инъекции приведут к тому, что пользовательский ввод появится после знака a = или его эквивалентного шестнадцатеричного значения.
2.2 Исправьте регулярное выражение для обнаружения метасимволов SQL
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Объяснение:
Это правило сначала обращает внимание на знак = или его шестнадцатеричное значение (%3D), затем учитывает ноль или более любых символов, кроме символов новой строки, и, наконец, обнаруживает одинарные кавычки и двойные тире или. точка с запятой.
Типичная SQL-инъекция попытается манипулировать исходным запросом, используя одинарные кавычки, чтобы получить полезное значение. Эта атака обычно обсуждается с использованием строки 1'or'1'='1. Однако обнаружение этой строки можно легко обойти, например, используя 1'or2>1 --. Однако единственной постоянной частью является значение. начальный символ, заключите его в одинарную кавычку и добавьте «или». Приведенная ниже булева логика может варьироваться в зависимости от стиля: от обычного до очень сложного. Эти атаки можно довольно точно обнаружить, используя следующее регулярное выражение. Глава 2.3 объясняет.
2.3 Типичное регулярное выражение атаки SQL-инъекцией
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (% 52))/ix
объяснение:
w* — ноль или более символов или символов подчеркивания.
(%27)|' — одинарная кавычка или ее шестнадцатеричный эквивалент.
(%6 F)|o|(%4 F))((%72)|r|-(%52) — случай «или» и его шестнадцатеричный эквивалент.
Union’SQL-запрос при SQL-инъекции атаки также очень распространены в различных базах данных. Если предыдущее регулярное выражение обнаруживает только одинарные кавычки или другие метасимволы SQL, это приведет к множеству ошибок. Вам следует дополнительно изменить запрос для обнаружения одинарных кавычек и ключей «объединения». также может быть дополнительно расширен другими ключевыми словами SQL, такими как «выбрать», «вставить», «обновить», «удалить» и т. д.
2.4 Обнаружение внедрения SQL, регулярное выражение ключевого слова запроса UNION
/ ((%27)|(') )union/ix
(%27)|(') — одинарная кавычка и ее шестнадцатеричный эквивалент
объединение. Ключевое слово объединение
также можно использовать для настройки выражений для других запросов SQL, таких как >выбрать, вставить, обновить, удалить, удалить и т. д.
Если на этом этапе злоумышленник обнаружил, что веб-приложение содержит SQL-инъекцию. уязвимость, он попытается ею воспользоваться. Если он поймет, что серверным сервером является сервер MS SQL, он обычно попытается запустить какое-нибудь опасное хранилище и расширенные хранимые процедуры. Эти процедуры обычно начинаются с букв «sp» или «xp». Обычно он может попытаться запустить расширенную хранимую процедуру xp_cmdshell (которая выполняет команды Windows через SQL Server). У органа SA SQL-сервера есть полномочия на выполнение этих команд. Аналогичным образом они могут изменять реестр с помощью xp_regread, xp_regwrite и других хранимых процедур.
2.5 Объяснение регулярного выражения
/exec(s|+)+(s|x)pw+/ix
для обнаружения атак SQL-инъекций MS SQL Server:
exec — ключевое слово, которое запрашивает выполнение хранимой или расширенной хранимой процедуры.
(s|+)+ — один или несколько пробелов или их http-эквивалентов.
(s|x) p-буквы «sp» или «xp» используются для обозначения процедур хранения или расширенного хранения.
w+ — один или несколько символов или символов подчеркивания, соответствующих имени процедуры
. 3. Регулярное выражение для межсайтового скриптинга (CSS).
При запуске CSS-атаки или обнаружении уязвимости веб-сайта злоумышленник может сначала создать простой HTML-тег, например <b> (жирный шрифт), <i> (курсив) или <u> (подчеркнутый), или он может попробовать простой тег сценария, например <script>alert("OK")</script>. Потому что большинство публикаций и This is is. используется в качестве примера для определения наличия на веб-сайте уязвимостей CSS, распространяемых через Интернет. Эти попытки можно легко обнаружить. Однако умный злоумышленник может заменить всю строку ее шестнадцатеричным значением. Таким образом, тег <script> будет выглядеть как %3C%73%63%72%69%70%74%3E. С другой стороны, злоумышленник может использовать веб-прокси-сервер, такой как Achilles, для автоматического преобразования некоторых специальных символов, таких как < в %3C, > в %3E. Когда происходит такая атака, угловые скобки обычно заменяются шестнадцатеричными значениями. в URL-адресе.
Следующее регулярное выражение обнаружит любой текст, содержащий <, > в html. Он перехватит попытки использовать <b>, <u> или <script>. Это регулярное выражение должно игнорировать регистр. Нам нужно обнаружить как угловую скобку, так и ее шестнадцатеричный эквивалент (% 3C|<). Чтобы обнаружить всю строку, преобразованную в шестнадцатеричный формат, мы должны обнаружить числа и знаки %, введенные пользователем, то есть использовать [a-z0-9%]. Это может привести к появлению некоторых ошибок, но не большинство из них обнаружит настоящие атаки.
3.1 Регулярное выражение для общих атак CSS
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
объяснение :
((%3C)|<) — проверяет < и его шестнадцатеричный эквивалент
((%2F)|/)* - закрывающий тег/ или его шестнадцатеричный эквивалент
[a-z0-9%]+ — проверить букву в теге или ее шестнадцатеричный эквивалент.
((%3E)|>) — проверьте наличие > или его шестнадцатеричного эквивалента
правила Snort:
alert tcp $EXTERNAL_NET любой -> $HTTP_SERVERS $HTTP_PORTS (msg:"Попытка выполнения межсайтового сценария NII"; поток:to_server,установлен; pcre:"/((%3C)|<)((%2F)| /)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Также можно использовать межсайтовые сценарии использованная< img src=>Технология. Текущие правила snort по умолчанию можно легко обойти.
В разделе 3.2 представлены методы предотвращения этой техники.
3.2 Регулярное выражение CSS-атаки "<img src"
/((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D) ) ((%67)|g|(%47))[^n]+((%3E)|>)/I
объяснение:
(%3 C)|<) -<или его шестнадцатеричный эквивалент
(%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47) -буква 'img' или она Варианты комбинаций шестнадцатеричных эквивалентов прописных и строчных букв
[^n]+ — любой символ, следующий за <img, кроме новой строки
(%3E)|>) -> или его шестнадцатеричный эквивалент
3.3 CSS Attack Extreme Regular Expression
/((%3C)|<)[^n]+((%3E)|>) /I
Объяснение:
Это Правило просто ищет <+любой символ, кроме символа новой строки+>. В зависимости от архитектуры вашего веб-сервера и веб-приложения это правило может вызывать некоторые ошибки. Но он гарантированно отразит любые атаки типа CCS или CSS.
Описание:
В этой статье мы предложили различные виды правил регулярных выражений для обнаружения атак SQL-инъекций и межсайтовых сценариев. Некоторые правила просты и экстремальны, и потенциальное нападение вызовет у вас тревогу. Но эти крайние правила могут привести к некоторым упреждающим ошибкам. Учитывая это, мы изменили эти простые правила, чтобы использовать дополнительные стили, чтобы их можно было проверять более точно. При обнаружении атак на эти сетевые приложения мы рекомендуем использовать их в качестве отправной точки для отладки вашей IDS или методов анализа журналов. После еще нескольких доработок вы будете готовы обнаружить эти атаки после того, как оцените незлонамеренные ответы на часть обычных сетевых транзакций.
Ссылка
1. SQL-инъекция
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. Часто задаваемые вопросы по межсайтовому скриптингу http://www.cgisecurity.com/articles/xss -
faq.shtml
3. Snort IDS http://www.snort.org.
4. Perl-совместимые регулярные выражения (pcre) http://www.pcre.org
5. Прокси-сервер веб-приложения Achilles http://achilles.mavensecurity.com
3. Расширенное внедрение SQL
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
7. HOWTO по безопасному программированию, Дэвид Уиллер www.dwheeler.com
8. Угрозы и меры противодействия, MSDN, Microsoft