Межсайтовое выполнение сценариев (Cross-site Scripting или XSS). Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Для написания подобного кода обычно используются HTML/JavaScript, но могут быть применены и VBScript, ActiveX, Java, Flash и др. Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя текущие привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера (здесь совсем не грех будет вспомнить, что, если вы работаете с правами администратора, шансов попасться на такой крючок больше). При данном виде атаки у атакованного пользователя может быть скомпрометирована учетная запись (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Передача кода в таких случаях осуществляется через URL, в заголовках HTML-запроса (cookie, user-agent, refferer), значениях полей форм и т. д. Существует два типа атак, приводящих к межсайтовому выполнению сценариев:
♦ постоянные (сохраненные);
♦ непостоянные (отраженные).
Основным различием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляются в рамках одного HTTP-запроса, а в сохраненном – в разных. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по электронной почте, ICQ и т. д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с веб-интерфейсом и чаты. Что самое интересное в данном случае? Следующее: для атаки пользователю не обязательно переходить по ссылке – достаточно посетить уязвимый сайт!
За примерами далеко ходить не приходится: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице. К примеру, при переходе по URL http://portaLexample/search?q="fresh beer" пользователю будет отображена страница, содержащая результаты поиска и фразу По вашему запросу fresh beer найдено 0 страниц. Если в качестве искомой фразы будет передан JavaScript-код, он выполнится в браузере пользователя.
Расщепление HTTP-запроса (HTTP Response Splitting). Для эксплуатации данной уязвимости злоумышленник должен послать серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера. Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках HTTP-ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie.
В первой ситуации URL-адрес, на который происходит перенаправление, является частью заголовка Location HTTP-ответа, а во втором случае значение cookie передается в заголовке Set-Cookie. Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две HTTP-транзакции, в то время как реально будет происходить только одна. Перевод строки используется, чтобы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно не предусмотренную логикой приложения. В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия.
♦ Межсайтовое выполнение сценариев.
♦ Модификация данных кэша сервера-посредника. Некоторые кэширующие серверы-посредники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других) сохраняют подделанный злоумышленником ответ на жестком диске и на последующие запросы пользователей по данному адресу возвращают кэшированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение cookie пользователя или присвоить им определенное значение. Эта атака может быть также направлена на индивидуальный кэш браузера пользователя.
♦ Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение с сервером между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы, злоумышленник может также выполнить различные операции с cookie пользователя.
♦ Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации. Приведу пример JSP-страницы:
/redir_lang.jsp<% response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter ("lang")); %>
Когда данная страница вызывается пользователем с параметром lang = English, она направляет его браузер на страницу /by_lang.jsp?lang=English. Типичный ответ сервера выглядит следующим образом (используется сервер BEA WebLogic 8.1 SP1) (листинг 1.9).
Листинг 1.9. Ответ сервера на запрос пользователя
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 12:53:28 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=English
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXj
ApqwBE! – 1251019693; path=/
Connection: Close
<html><head><title>302 Moved Temporarily</title></head>
<body bgcolor="#FFFFFF">
<p>This document you requested has moved temporarily.</p>
<p>It's now at <a
href="httр://10.1.1.1/by_lang.jsp?lang=English">httр://10.1.1.1/by_lang.jsp?lan
g=English</a>.</p>
</body></html>
При анализе ответа видно, что значение параметра lang передается в значении заголовка Location. При реализации атаки злоумышленник посылает в качестве значения lang символы перевода строки, чтобы закрыть ответ сервера и сформировать еще один:
/redir_lang.jsp?lang=foobar%0d%0aContent-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-
Length:%2019%0d%0a%0d%0a<html>Shazam</html>
При обработке этого запроса сервер передаст следующие данные (листинг 1.10).
Листинг 1.10. Ответ сервера на измененный злоумышленником запрос пользователя
HTTP/1.1 302 Moved Temporarily
Date: Wed, 24 Dec 2003 15:26:41 GMT
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
Shazam</html>
Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003
271009 with
Content-Type: text/html
Set-Cookie:
JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST
9UsS! – 1251019693; path=/
Эти данные будут обработаны клиентом следующим образом:
♦ первый ответ с кодом 302 будет командой перенаправления;
♦ второй ответ (код 200) объемом в 19 байт будет считаться содержимым той страницы, на которую происходит перенаправление;
♦ остальные данные, согласно спецификации HTTP, игнорируются клиентом. Выполнение кода
Все серверы используют данные, переданные пользователем при обработке запросов. Часто эти данные используются при составлении команд, применяемых для генерации динамического содержимого. Если при разработке не учитываются требования безопасности, злоумышленник получает возможность модифицировать исполняемые команды. В настоящее время выделяют несколько типов атак, направленных на выполнение кода на веб-сервере.
Переполнение буфера (Buffer Overflow). Переполнение буфера на сегодняшний день является самой распространенной уязвимостью в области безопасности ПО. Первая атака с применением данной уязвимости использовалась в вирусе-черве Морриса в 1988 году. Червь, созданный студентом Корнельского университета, всего спустя пять часов после активации умудрился инфицировать около 6000 компьютеров – по сегодняшним меркам не очень много, но не будем забывать про год! Среди пострадавших – такие монстры, как Агентство Национальной безопасности и Стратегического авиационного командования США, лаборатории NASA (в частности, в вычислительном центре NASA в Хьюстоне червь попытался взять под контроль систему запуска кораблей многоразового использования Space Shuttle). Помимо прочего, червь успел насытить свои низменные гастрономические пристрастия исследовательским центром ВМС США, Калифорнийским НИИ, крупнейшими университетами страны, а также рядом военных баз, клиник и частных компаний. С тех пор количество способов реализации атак на переполнение буфера только увеличилось.
Эксплуатация переполнения буфера позволяет злоумышленнику изменить путь исполнения программы методом перезаписи данных в памяти системы. Переполнение возникает, когда объем данных превышает размер выделенного под них буфера. Когда буфер переполняется, данные переписывают другие области памяти, что приводит к возникновению ошибки. Если злоумышленник имеет возможность управлять процессом переполнения, это может вызвать ряд серьезных проблем.
Переполнение буфера может вызывать отказы в обслуживании, приводя к повреждению памяти и вызывая ошибки в программах. Более серьезные ситуации позволяют изменить путь исполнения программы и выполнить в ее контексте различные действия. Это может происходить в нескольких случаях.
Используя переполнение буфера, можно перезаписывать служебные области памяти, например адрес возврата из функций в стеке. Кроме того, при переполнении могут быть переписаны значения переменных в программе.
Переполнение буфера является наиболее распространенной проблемой в безопасности и нередко затрагивает веб-серверы. Однако атаки, эксплуатирующие эту уязвимость, используются против веб-приложений не очень часто. Причина этого кроется в том, что атакующему, как правило, необходимо проанализировать исходный код или образ программы. Поскольку атакующему приходится эксплуатировать нестандартную программу на удаленном сервере, он вынужден атаковать "вслепую", что снижает шансы на успех.
Переполнение буфера обычно возникает при создании программ на языках C и C++. Если часть сайта создана с использованием этих языков, сайт может быть уязвим для этой атаки.
Атака на функции форматирования строк (Format String Attack). При использовании этих атак путь исполнения программы модифицируется методом перезаписи областей памяти с помощью функций форматирования символьных переменных. Уязвимость возникает, когда пользовательские данные применяются в качестве аргументов функций форматирования строк, таких как fprintf, printf, sprintf, setproctitle, syslog и т. д. Если атакующий передает приложению строку, содержащую символы форматирования (%f, %p, %n и т. д.), то у него появляется возможность:
♦ выполнять произвольный код на сервере;
♦ считывать значения из стека;
♦ вызывать ошибки в программе/отказ в обслуживании.
Вот пример: предположим, веб-приложение хранит параметр emailAddress для каждого пользователя. Это значение используется в качестве аргумента функции printf: printf(emailAddress). Если значение переменной emailAddress содержит символы форматирования, то функция printf будет обрабатывать их согласно заложенной в нее логике. Поскольку дополнительных значений этой функции не передано, будут использованы значения стека, хранящие другие данные.
Возможны следующие методы эксплуатации атак на функции форматирования строк.
♦ Чтение данных из стека. Если вывод функции printf передается атакующему, он получает возможность чтения данных из стека, используя символ форматирования %x.
♦ Чтение строк из памяти процесса. Если вывод функции printf передается атакующему, он может получать строки из памяти процесса, передавая в параметрах символ %s.
♦ Запись целочисленных значений в память процесса. Используя символ форматирования %n, злоумышленник может сохранять целочисленные значения в памяти процесса. Таким образом можно перезаписать важные значения, например флаги управления доступом или адрес возврата.
Внедрение операторов LDAP (LDAP Injection). Атаки этого типа направлены на веб-серверы, создающие запросы к службе LDAP на основе данных, вводимых пользователем. Упрощенный протокол доступа к службе каталога (Lightweight Directory Access Protocol, LDAP) – открытый протокол для создания запросов и управления службами каталога, совместимыми со стандартом X.500. Протокол LDAP работает поверх транспортных протоколов Интернет (TCP/UDP). Веб-приложение может использовать данные, предоставленные пользователем для создания запросов по протоколу LDAP при генерации динамических веб-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать LDAP-запрос. Причем запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). Если данный компонент имеет права на чтение или модификацию данных в структуре каталога, злоумышленник получает те же возможности. В листинге 1.11 представлен пример кода, который может быть подвержен атаке данного вида.
Листинг 1.11. Уязвимый код с комментариями
line 0: <html>
line 1: <body>
line 2: <%@ Language=VBScript %>
line 3: <%
line 4: Dim userName
line 5: Dim filter
line 6: Dim ldapObj
line 7:
line 8: Const LDAP_SERVER = "ldap.example"
line 9:
line 10: userName = Request.QueryString("user")
line 11:
line 12: if( userName = "" ) then
line 13: Response.Write("<b>Invalid request. Please specify a valid user name</b><br>")
line 14: Response.End()
line 15: end if
line 16:
line 17:
line 18: filter = "(uid=" + CStr(userName) + ")" " searching for the user entry
line 19:
line 20:
line 21: "Creating the LDAP object and setting the base dn
line 22: Set ldapObj = Server.CreateObject("IPWorksASP.LDAP")
line 23: ldapObj.ServerName = LDAP_SERVER
line 24: ldapObj.DN = "ou=people,dc=spilab,dc=com"
line 25:
line 26: 'Setting the search filter
line 27: ldapObj.SearchFilter = filter
line 28:
line 29: ldapObj.Search
line 30:
line 31: 'Showing the user information
line 32: While ldapObj.NextResult = 1
line 33: Response.Write("<p>")
line 34:
line 35: Response.Write("<b><u>User information for: " + ldapObj.AttrValue(0) + "</u></b><br>")
line 36: For i = 0 To ldapObj.AttrCount-1
line 37: Response.Write("<b>" + ldapObj.AttrType(i) +"</b>: " + ldapObj.AttrValue(i) + "<br>" )
line 38: Next
line 39: Response.Write("</p>")
line 40: Wend
line 41: %>
line 42: </body>
line 43: </html>
Обратите внимание, что имя пользователя, полученное от клиента, проверяется на наличие в этой строке пустого значения (строки 10-12). Если в переменной содержится какое-то значение, оно используется для инициализации переменной filter (строка 18). Полученное значение используется для построения запроса к службе LDAP (строка 27), который исполняется в строке 29. В приведенном примере атакующий имеет полный контроль над запросом и получает его результаты от сервера (строки 32-40).
Выполнение команд операционной системы (OS Commanding). Атаки этого класса направлены на выполнение команд операционной системы на веб-сервере путем манипуляции входными данными. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность выполнить команды операционной системы. Они будут выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). Пример: язык Perl позволяет перенаправлять вывод процесса оператору open, используя символ | в конце имени файла:
#Выполнить "/bin/ls" и передать
#результат оператору
open Open (FILE, "/bin/ls|")
Веб-приложения часто используют параметры, которые указывают на то, какой файл отображать или использовать в качестве шаблона. Если этот параметр не проверяется достаточно тщательно, атакующий может подставить команды операционной системы после символа | . Предположим, приложение оперирует URL следующего вида: http://example/cgi-bin/showInfo.pl?name=John&template=tmp1.txt.
Изменяя значение параметра template, злоумышленник дописывает необходимую команду (/bin/ls) к используемой приложением:
http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls|
Большинство языков сценариев позволяет запускать команды операционной системы во время выполнения, используя варианты функции exec. Если данные, полученные от пользователя, передаются этой функции без проверки, злоумышленник может выполнить команды операционной системы удаленно. Следующий пример иллюстрирует уязвимый PHP-сценарий:
exec("ls-la $dir",$lines,$rc);