На дворе вот уже более месяца стоит плохая, дождливая погода. И нет ничего лучше, как провести это скучное время за чтением свежего номера своей любимой газеты. А о чем же сегодня будем читать?? В прошлых номерах КГ аналитики SASecurity gr. рассматривали самые разнообразные уязвимости Интернет ресурсов, такие как XSS, SQL-inj, drive-by атаки, man-in-the-middle и так далее. В этой статье я продолжу рассказ, а говорить буду об CSRF атаке. А начнем мы, как обычно, с истории

Как оно было

Впервые о данном типе уязвимости заговорили в далеком 1988 году, когда Norm Hardy опубликовал документ под заголовком “The confused Deputy: (or why capabilities might have been invented)”, объясняющий подозрительное доверие веб-приложений к принимаемым данным, назвав это явление, как видно из названия заметки, «confused deputy». На практике примеры реализации атак подобного рода были приведены в bugtruck только в 2000, когда Jim Fulton написал статью “Client Side Trojan” на сайте zope.org. Сам термин “CSRF ” был введен Питером Ваткинсоном в 2001 году, он использовался в его заметке под названием «The Dangers of Allowing Users to Post Images». Почитать оригинальную статью можно по адресу http://www.tux.org/~peterw/csrf.txt , правда, это можно сделать только владея английским языком. Новая на то время уязвимость получила название Cross-Site Request Forgery (сокращенно CSRF или XSRF), что в переводе на русский означает «подделка межсайтовых запросов». Если Вы где-нибудь увидите фразы типа «Session Riding» или «Confused Deputy Attack», не пугайтесь – это всего лишь еще несколько вариантов именования уязвимостей данного класса. Довольно опасным оказался взлом почтового сервиса Gmail в январе 2007. С помощью XSRF атаки можно было украсть контактный список любого пользователя. А теперь представьте, скольким людям можно было разослать спам или вредоносное ПО! В 2008 году подобная уязвимость была обнаружена на сайте New York Times, в конце этого же года на сайте YouTube. Если же говорить простым и понятным всем языком, то CSRF – это вид атак на посетителей веб-сайтов, использующие недостатки протокола HTTP. Возьмем самый простой пример: жертва посещает сайт, созданный злоумышленником, и от ее лица скрытно отправляется запрос на другой сервер. В реальной жизни чаще всего это какие-нибудь платежные системы. В результате такого запроса может быть осуществлена скрытая транзакция ну или то-то в этом дехе. Для осуществления данной атаки, жертва должна быть авторизована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, который не может быть проигнорирован или подделан атакующим скриптом. Многие ошибочно считают, что данный тип уязвимости тесно связан с Cross-Site Scripting атакой, но это лишь распространенное заблуждение. Единственное, в чем схожи CSRF и XSS, так это использование в качестве вектора атаки клиентов Web-приложений (так называемая Client-Side Attack). В реальной жизни CSRF атака может эксплуатироваться как совместно с XSS, так и без нее – все же она представляет собой отдельный класс уязвимостей. Хотя вместе они дают более насыщенный функционал для злоумышленника.

Зачем оно надо и как это организовать?

Одно из применений XSRF — эксплуатация пассивных XSS, обнаруженных на другом сервере. Так же возможны отправка спама от лица жертвы и изменение каких-либо настроек учётных записей на других сайтах (например, секретного вопроса для восстановления пароля или альтернативного e-mail). Достаточно вспомнить обнаруженный в 2008 году баг на чрезвычайно популярном российском ресурсе ВКонтакте. Используя CRSF атаку можно было подменить в любом профиле поле «Веб-сайт». Делалось это с использование скрипта, код которого можно увидеть на рисунке 1:



Если внимательно пересмотреть данный код, то можно заметить, что при запросе картинки по адресу http://vkontakte.ru/profileEdit.php?page=contacts&subm=1&website=http://tvoydohod.com, браузер попытается обратиться к этому URL, в результате чего он непреднамеренно сменит в анкете значение поля «Веб-сайт» на «http://tvoydohod.com» (смотрим рисунок 2).



И так можно было сменить и другие поля. Вторым примером CSRF атаки является давно известная (и уже устраненная админами) CSRF уязвимость на первом почтовом сервисе России Mail.ru, датированная приблизительно 2004 годом. Дыра заключалась в следующем: хакер, будь то злоумышленник или простой пользователь, жаждущий почитать чужую почту, создает специальную web-страничку и размещает ее на каком-нибудь хостинге. Далее он создает письмо, где просит пользователя перейти по ссылке, ведущей на эту страничку, и отсылает его жертве. Последняя, в свою очередь, прочитав почту наивно переходит по ссылке. В это время скрытый в недрах HTML тегов скрипт осуществляет подмену альтернативного e-mail на указанный взломщиком. Эти данные передавались на URL http://win.mail.ru/cgi-bin/anketa методом POST. Код скрипта формы указан на рисунке 3:



Вторым способом смены альтернативного мыла на этом же сервисе является переход жертвы по ссылке, имеющей вид http://win.mail.ru/cgi-bin/anketa?page=2&Email=test@sa-sec.org. Здесь идет эксплуатация метода GET, где в качестве параметра переменной Email указывается любой почтовый адрес (в нашем случае это test@sa-sec.org). А использовать этот способ можно так же, как и на сайте ВКонтакте. В этом и ранее указанном случаях злоумышленник может получить доступ к почтовому ящику пользователя, просто запросив пасс на страничке восстановления забытого пароля, указав в качестве дополнительного e-mail адрес test@sa-sec.org.

Вообще данный тип уязвимости тем и интересен, что он не является результатом ошибок программистов, а является нормальным поведением Web-сервера и браузера. Поэтому ее довольно сложно обнаружить, но защититься все же можно. Как?? Читаем дальше.

Организация защиты

Почему-то многие люди считают, что использование метода POST вместо GET поможет защитить веб-приложение от атак подобного рода, но приведенный мною выше пример получения доступа к мылу в пух и прах развевает это распространенное заблуждение. Второй способ – это реализация страниц подтверждения. На самом деле данный способ лишь немного затрудняет осуществление атаки тем, что необходимо делать два запроса вместо одного. Для качественной защиты от данного типа атак, веб-сайты должны требовать подтверждения большинства действий пользователя и проверять поле HTTP referer, если оно указано в запросе.

Лучше всего использовать случайный идентификатор, именуемый маркером доступа (token), который генерируется для каждой операции и необходим для ее выполнения. Он помогает эффективно различать запросы, что защищает сайт от CSRF-атак. Код генерации (пишем его, естественно, на PHP) такого маркера выглядит примерно следующим образом:

Случайный маркер в нашем случае создается на основе MD5 хешировании метки времени (функция microtime) и случайного числа (функция mt_rand), после чего записывается в массив $_SESSION. Далее в каждой форме на сайте добавляем hidden-поле с идентификатором:

После чего в каждом запросе необходимо проверять корректность маркера доступа:

Анализируя код, мы видим, что изначально в переменную $token записывается значение маркера доступа. Далее идет сравнение его с оригиналом и в случае совпадения выполнение требуемых действий. Если же наш токен оказался неверным (видимо CSRF атака), то прекращаем выполнение сценария и выдаем ошибку (функция die). Данный метод очень прост в реализации, но очень эффективен для защиты. Еще одним необходимым действием, которое необходимо провести, это хорошенько проверить сайт на наличие XSS уязвимостей, ведь как я говорил ранее, связка этих двух компонентов вполне реальна и довольна эффективна.

Насколько велика угроза?

Данные, полученные компанией Positive Technologies (я думаю, ее много кто знает хотя бы по программе XSpider) в ходе работ по тестированию на проникновение и оценки защищенности Web-приложений, показывают, что этой уязвимости подвержена большая часть Web-приложений. А что это может означать? То, что большая часть форумов, почтовых сервисов и подобных ресурсов не в состоянии удержать наши конфиденциальные данные от злоумышленников. Поэтому будьте бдительны, и если будете создавать свой сайт, не поленитесь защитить себя от XSRF атак, ведь это не сложно

P.S.: Информация предоставлена исключительно для ознакомления и изучения. Автор и SASecurity gr. не несут ответственности за использование данной информации в злонамеренных целях.

(c) Bulka, оригинал статьи