[Перевод] Государственный университет Адамс. Как взламывать веб-сайты. Часть 2
Государственный университет Адамс. Как взламывать веб-сайты. Часть 1
Давайте поговорим о нашей следующей атаке. Расскажу, как серверы вас идентифицируют. Для этого между браузером и сервером используется протокол HTTP без сохранения состояния, когда общение с сервером происходит независимыми парами «запрос-ответ». Поэтому сервер вас забывает, как только установлена связь, и при следующем сеансе уже не помнит, кто вы такой.
Однако он помнит вас, пока вы пользуетесь веб-приложением, потому что когда вы кладёте в корзину вещи, которые собираетесь купить, то можете продолжить покупки и снова вернуться, чтобы просмотреть содержание своей корзины. Реализация «запоминания» происходит при помощи кукиз идентификации сеанса. Как только вы залогинились на сервере, он генерирует файл куки, который представляет собой уникальную последовательность букв и цифр, и отправляет его вашему браузеру, который сохраняет это куки локально на вашем компьютере. После этого браузер возвращает кукиз серверу с каждым вашим запросом на протяжение одного сеанса. Получая эти кукиз, сервер понимает, что за пользователь обращается к нему с данным запросом. Это самый распространенный способ идентификации пользователя, который пользуется веб-приложением.
Следующий тип атаки носит название «межсайтовый скриптинг», XSS. Идея этой атаки в том, что злоумышленник принуждает веб-сайт отображать вредоносный код, обычно в виде JavaScript, который затем исполняется в браузере пользователя. Такая атака может преследовать любую цель, но чаще всего используется для получения идентификатора сеанса жертвы. Ценность Session ID состоит в том, что его можно рассматривать в качестве пароля, так как он идентифицирует вас. Захватив идентификатор сеанса, злоумышленник может замаскироваться под вас, используя прокси-сервер для связи с целевым сервером. Целями такой атаки может быть желание выступать от вашего лица, автоматизировать какие-то действия, например, рассылку спама, от вашего имени, или внедрить вирус.
При поиске уязвимости межсайтового скриптинга XSS в веб-приложении вы ищите поле ввода, в котором можно поместить некоторую информацию, отослать её на сервер и посмотреть, какой результат отобразится в окне браузера.
Я неправильно ввожу расположение здания, указав Plachy Hall, адрес зала баскетбольной команды нашего университета. Веб-сервер получает эту информацию и соображает, что профессор компьютерных наук — это «ботан», который не может обитать в месте расположения спортивной команды, и выдаёт сообщение об ошибке: «Plachy Hall — это неправильно»!
Наиболее уязвимы в этом отношении окна поиска, куда вы можете ввести некоторые довольно неясные термины, а затем посмотреть, что получите в ответ. Чаще всего вам выдается подсказка с перечислением возможных правильных вариантов, которыми может воспользоваться злоумышленник.
Следующее, что вам нужно сделать, это проверить, сможете ли вы внедрить свой вредоносный код и затем его выполнить. Мы попробуем организовать XSS атаку при помощи JavaScript.
Код JavaScript всегда выделяется открытием и закрытием тега script, а также оператором OR. Разработчики приложений не совсем глупы, поэтому они установили механизм фильтрации, называемые «дезинфекцией». Он внедряется внутрь кода, проверяет, нет ли там опасных символов, и по возможности удаляет их. Простейший тест «дезинфекции» JavaScript выглядит так:
Но хакеры немного умнее, поэтому у них имеется сайт ha.ckers.org/xss.html. У меня нет времени, чтобы показать вам этот сайт, но там можно найти самые изощренные способы обхода элементов управления, которые разработчики приложений попытались вставить в свои программы, чтобы удалить опасные символы. Так что существуют довольно хитроумные способы, позволяющие хакеру проникнуть внутрь приложения.
Итак, давайте поговорим о том, как будет проходить XSS- атака. У нас имеется веб-сервер «Факультетских страничек», куда мы собираемся ввести вредоносный код. У нас есть Ева, которая собирается совершить взлом, но мы что-то пропустили на этом слайде — мы забыли про жертву. Что хорошего в XSS-атаке, это то, что вам не нужно никого для этого нанимать. Я имею в виду, что на этот раз не собираюсь быть жертвой, потому что у Евы есть мой пароль и она может сделать с моим аккаунтом все, что захочет. Поэтому Ева выходит из большой игры и больше не гоняется за маленькими мальчиками. Давайте выведем на сцену нашу жертву (смех в аудитории, потому что на слайде появляется фотография одного из профессоров факультета).
Теперь, когда жертва заняла своё место, давайте посмотрим, как будет развиваться атака. Предположим, что Еве удалось разместить вредоносный код JavaScript на сервере, куда собирается войти наша жертва, используя для этого свою учётную запись.
Это важно, потому что как только жертва залогинится на сервере, она получит идентификатор сеанса, который Ева постарается перехватить, это очень важная часть атаки. Итак, жертва запрашивает веб-страничку, которая содержит вредоносный код JavaScript, этот код выполнится в браузере жертвы и отправит Еве идентификатор сеанса.
Получив идентификатор сеанса, Ева может использовать свой прокси-сервер и делать всё, что захочет, маскируясь под жертву. Единственный недостающий кусочек мозаики — это сам вредоносный JavaScript, который хакер должен вставить в страницу и который должен захватить наш идентификатор сеанса жертвы и передать его злоумышленнику.
Это очень просто. У нас имеется код JavaScript, который начинается и заканчивается открытием и закрытием тега:
