n1†R0x
21.04.2007, 17:23
В последнее время в сообществе специалистов по безопасности Web-приложений широко обсуждается «новый» тип уязвимостей, получивший название Cross-Site Request Forgery (CSRF или XSRF). Предлагаемая вниманию читателя статья содержит описание этого типа уязвимостей, методов его использования и основные походы к защите. Общепринятый русский термин для обозначения Cross-Site Request Forgery ещё не устоялся, в связи с чем автор предлагает использовать вариант «Подделка HTTP-запросов».
Лирическое отступление
Прежде всего, хотелось бы остановиться на основных заблуждениях связанных с CSRF:
1. Подделка HTTP-запросов – новый тип уязвимостей.
Это далеко не так. Теоретические размышления на тему подделки источника сообщений датированы 1988 годом (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), а практические примеры уязвимостей обсуждаются в Bugtraq как минимум с 2000 года (http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Сам термин введен Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) в 2001 году.
2. CSRF – это вариант Межсайтового выполнения сценариев (XSS).
Единственное сходство между CSRF и XSS, это использование в качестве вектора атаки клиентов Web-приложений (Client-Side Attack в терминологии WASC http://www.webappsec.org/projects/threat/). Уязвимости типа CSRF могут эксплуатироваться совместно с XSS или «редиректорами» (http://www.securitylab.ru/analytics/283136.php), но представляют собой отдельный класс уязвимостей.
3. Уязвимость CSRF мало распространена и достаточно сложна в использовании.
Данные, полученные компанией Positive Technologies в ходе работ по тестированию на проникновение и оценки защищенности Web-приложений показывают, что этой уязвимости подвержена большая часть Web-приложений. В отличие от других уязвимостей CSRF возникает не в результате ошибок программирования, а является нормальным поведением Web-сервера и браузера. Т.е. большинство сайтов, использующих стандартную архитектуру уязвимы «по умолчанию».
Пример использования
Давайте рассмотрим использование CSRF на примере. Предположим, существует некое Web-приложение, отправляющее сообщения электронной почты. Пользователь указывает адрес электронной почты и текст сообщения, нажимает кнопку Submit и сообщение от его адреса передается получателю.
http://img221.imageshack.us/img221/7114/1messagetw0.png
Отправка сообщения
Схема знакома по множеству сайтов и не вызывает никаких возражений. Однако указанное приложение с большой вероятности уязвимо для атак «Подделка HTTP-запроса». Для эксплуатации уязвимости злоумышленник может создать на своем сайте страницу содержащую ссылку на «изображение», после чего заставить пользователя перейти по ссылке на свой сайт (например, http://bh.ptsecurity.ru/xcheck/csrf.htm).
<img src="http://test.ptsecurity.ru/xcheck/send.asp?to=user@example.com&mess=Spam+The">
При обращении к странице браузер пользователя пытается загрузить изображение, для чего обращается к уязвимому приложению, т.е. оправляет сообщение электронной почты адресату, указанному в поле «to» запроса.
http://img95.imageshack.us/img95/4507/2senthb3.png
XSRF-атака
Обратите внимание, что браузер пользователя отправит сайту значение Cookie, т.е. запрос будет воспринят как исходящий от аутентифицированного пользователя. Для того чтобы заставить пользователя загрузить страницу, отправляющую запрос к уязвимому серверу, злоумышленник может использовать методы социальной инженерии, а также технические уязвимости, такие как XSS и ошибки в реализации функции перенаправления.
http://img181.imageshack.us/img181/9158/3csrfschemdm7.png
Логика работы XSRF
Таким образом, атака с использованием CSRF заключается в использовании браузера пользователя для передачи HTTP-запросов произвольным сайтам, а уязвимость – в отсутствии проверки источника HTTP-запроса. Приведенное в примере приложение использует HTTP-метод GET для передачи параметров, что упрощает жизнь злоумышленнику. Однако не стоит думать, что использование метода POST автоматически устраняет возможность проведения атак с подделкой HTTP-запроса. Страница на сервере злоумышленника может содержать готовую HTML-форму, автоматически отправляемую при просмотре страницы.
<html>
<body>
<form method=POST action="http://test.ptsecurity.ru/xcheck/postsend.asp"> Mail to:
<br><br>
<input type=text name=to value="user2spam@example.com"><br><br> Message:
<br><br>
<textarea width=20 name=mess>Spam The</textarea><br><br> <input type=submit id=doit> </form>
<script> document.getElementById("doit").click(); </script>
</body>
</html>
Для эксплуатации CSRF злоумышленнику совсем не обязательно иметь свой Web-сервер. Страница, инициирующая запрос может быть передана по электронной почте или другим способом.
В обзоре Billy Hoffman (http://www.gnucitizen.org/blog/javascript-remoting-dangers) приведены различные методы сетевого взаимодействия с помощью Javascript. Все они, включая XmlHttxmpquest (в некоторых ситуациях), могут быть задействованы для реализации атак CSRF.
Надеюсь, что сейчас читателю уже понятно основное отличие CSRF от XSS. В случае с XSS злоумышленник получает возможность доступа к DOM (Document Object Model) уязвимой страницы, как на чтение, так и на запись. При выполнении CSRF атакущий имеет возможность передать запрос серверу с помощью браузера пользователя, но получить и проанализировать ответ сервера, а тем более его заголовок (например, Cookie) уже не сможет. Соответственно, «Подделка HTTP-запросов» позволяет работать с приложением в режиме «только на запись», чего впрочем, вполне достаточно для выполнения реальных атак.
Основными целями CSRF-атак являются различные интерактивные Web-приложения, например системы электронной почты, форумы, CMS, интерфейсы удаленного управления сетевым оборудованием. Например, злоумышленник может отправлять сообщения от имени других пользователей, добавлять новые учетные записи, или изменять настройки маршрутизатора через Web-интерфейс.
http://img262.imageshack.us/img262/2241/4csrfui4.png
Пример эксплуатации XSRF в форуме
Остановимся подробнее на последнем – изменении настроек сетевых устройств. Автор уже упоминал об этой возможности (http://www.securitylab.ru/analytics/275562.php) по отношению к системам обнаружения беспроводных атак, но естественно, ими дело не ограничивается.
Пробиваем периметр
В декабре прошлого года компания Symantec опубликовала отчет (http://www.symantec.com/avcenter/reference/Driveby_Pharming.pdf) о «новой» атаке, под называнием «Drive-By Pharming», которая, по сути, является вариантом эксплуатации CSRF. Злоумышленник выполняет в браузере пользователя некий «волшебный» JavaScript, изменяющий настройки маршрутизатора, например устанавливающего новое значение DNS-сервера. Для выполнения этой атаки необходимо решить следующие задачи:
- сканирование портов с помощью JavaScript;
- определение типа Web-приложения (fingerprint);
- подбор пароля и аутентификация с помощью CSRF;
- изменение настроек узла с помощью атаки CSRF.
Техника сканирования определения доступности Web-сервера и его типа по с помощью javascript (http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html) проработана достаточно хорошо и сводится к динамическому созданию HTML-объектов (например, img src=), указывающие на различные внутренние URL (например, http://192.168.0.1/pageerror.gif). Если «картинка» была успешно загружена, то по тестируемому адресу расположен Web-сервер на базе Microsoft IIS. Если в ответ было получена ошибка 404, то порт открыт и на нем работает Web-сервер. В случае если был превышен таймаут – сервер отсутствует в сети или порт заблокирован на межсетевом экране. Ну и в остальных ситуациях – порт закрыт, но хост доступен (сервер вернул RST-пакет и браузер вернул ошибку до истечения таймаута). В некоторых ситуациях подобное сканирование портов из браузера пользователя может проводиться без использования JavaScript (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).
После определения типа устройства злоумышленник может попробовать заставить браузер пользователя сразу послать запрос на изменение настроек. Но такой запрос будет успешен только в случае, если браузер пользователя уже имеет активную аутентифицированную сессию с устройства. Иметь под рукой открытую страницу управления маршрутизатором - дурная привычка многих «продвинутых» пользователей.
Если же активной сессии с интерфейсом управления нет, злоумышленнику необходимо пройти аутентификацию. В случае если в устройстве реализована аутентификация на основе форм, никаких проблем не возникает. Используя CSRF в POST, серверу отправляются запрос на авторизацию, после чего с него загружается изображение (или страница) доступная только аутентифицированным пользователям. Если изображение было получено, то аутентификация прошла успешно, и можно приступать к дальнейшим действиям, в обратном случае – пробуем другой пароль.
В случае если в атакуемом устройстве реализована аутентификация по методу Basic, задача усложняется. Браузер Internet Explorer не поддерживает возможность указать имя пользователя и пароль в URL (например, http://user:рass@test.ptsecurity.ru). В связи с этим для выполнения Basic-аутентификации может использоваться метод с добавлением HTTP-заголовков с помощью Flash, описанный в статье Amit Clein (http://www.securitylab.ru/analytics/271169.php) . Однако этот метод подходит только для старых версий Flash, которые встречаются все реже и реже.
Но другие браузеры, например Firefox дают возможность указать имя пользователя и пароль в URL, и могут быть использованы для аутентификации на любом сервере, причем это можно сделать без генерации сообщения об ошибке в случае выбора неверного пароля.
Пример сценария для «тихой» аутентификации по методу Basic, из блога Stefan Esser (http://blog.php-security.org/archives/56-Bruteforcing-HTTP-Auth-in-Firefox-with-JavaScript.html) приведен ниже.
<html>
<head>
<title>Firefox HTTP Auth Bruteforcing</title>
<script> function okPW() { alert("User/Password Combination correct"); } function wrongPW() { alert("User/Password Combination is wrong"); } </script> <link rel="shortcut icon" href="http://user:pass@URL" type="image/x-icon">
</head>
<body> <img src="http://www.securitylab.ru/_article_images/2007/03/http://user:pass@URL" onLoad="okPW()" onError="wrongPW()">
</body>
</html>
http://img459.imageshack.us/img459/9418/5ffbasichu2.png
Аутентификация Basic в Firefox
В корпоративной среде, где зачастую используются механизмы SSO, например, на базе домена Active Directory и протоколов Kerberos и NTLM эксплуатация CSRF не требует дополнительных усилий. Браузер автоматически пройдет аутентификацию в контексте безопасности текущего пользователя.
После того как аутентификация была пройдена, злоумышленник с помощью JavaScript передать запрос, изменяющий произвольные настройки маршрутизатора, например адрес DNS-сервера.
Методы защиты
Первое, что приходит на ум, когда речь заходит о защите от CSRF – это проверка значения заголовка Referer. И действительно, поскольку подделка HTTP-запросов заключается в передаче запроса с третьего сайта, контроль исходной страницы, чей адрес автоматически добавляется браузером в заголовки запроса, может решить проблему.
Однако этот механизм имеет ряд недостатков. Во-первых – перед разработчиком встает вопрос об обработке запросов, не имеющих заголовка Referer как такового. Многие из персональных межсетевых экранов и анонимизирующих proxy-серверов вырезают Referer, как потенциально небезопасный заголовок. Соответственно, если сервер будет игнорировать подобные запросы, группа наиболее «параноидально» настроенных граждан не смогут с ним работать.
Во-вторых, в некоторых ситуациях заголовок Referer может быть подделан, например, с помощью уже упоминавшегося трюка с Flash. Если пользователь применяет IE 6.0, то содержимое заголовка запроса может быть модифицировано c использованием ошибки в реализации XmlHttxmpquest. Уязвимость заключается в возможности использования символов перевода строки в имени HTTP-метода, что позволяет изменять заголовки и даже внедрять дополнительный запрос. Эта уязвимость была обнаружена Amit Clein (http://www.securityfocus.com/archive/1/411585) в 2005 году и снова открыта в 2007. Ограничением этого метода является то, что он работает только в случае наличия между пользователем и сервером HTTP-Proxy или размещения серверов на одном IP-адресе, но с разными доменными именами.
Другой распространенный метод – добавление уникального параметра к каждому запросу, который затем проверяется сервером. Параметр может добавляться к URL при использовании GET запроса как например, в Google Desktop (http://www.watchfire.com/Fresources/Overtaking-Google-Desktop.pdf) или в виде спрятанного параметра формы, при использовании POST. Значение параметра может быть произвольным, главное, чтобы злоумышленник не мог его предсказать, например – значение сессии пользователя.
http://img132.imageshack.us/img132/6065/6bitrxt6.png
Защита от XSRF в Bitrix
Для быстрого добавления функции проверки CSRF в свое приложение можно воспользоваться следующим подходом:
1. Добавлять в каждую генерируемую страницу небольшой JavaScript, дописывающий во все формы дополнительный скрытый параметр, которому присваивается значение Cookie.
2. Проверять на сервере, что переданные клиентом с помощью метода POST данные содержат значение, равное текущему значению Cookie.
Пример подобного клиентского сценария приведен ниже:
<script>
strCookie = document.cookie;
for (i=0;i<document.forms.length;i++)
{
var newTextField = document.createElement('input');
newTextField.setAttribute('type','hidden');
newTextField.setAttribute('name','session');
newTextField.value=strCookie; document.forms[i].appendChild(newTextField);
}
</script>
Дальнейшим развитием этого подхода является сохранение идентификатора сессии не в Cookie, а в качестве скрытого параметра формы (например, VIEWSTATE).
В качестве метода противодействия CSRF могут использоваться различные варианты тестов Тьюринга, например, хорошо известные всем изображения - CAPTCHA. Другим популярным вариантом является необходимость ввода пользовательского пароля при изменении критичных настроек.
http://img178.imageshack.us/img178/61/7maillp7.png
Защита от XSRF в mail.ru
Таким образом, Cross-Site Request Forgery являются атакой, направленной на клиента Web-приложения и использующей недостаточную проверку источника HTTP-запроса. Для защиты от подобных атак может использоваться дополнительный контроль источника запроса на основе заголовка Referer или дополнительного «случайного» параметра.
Сергей Гордейчик
gоrdey @ ptsеcurity com
Источник (http://www.securitylab.ru/analytics/292473.php)
Лирическое отступление
Прежде всего, хотелось бы остановиться на основных заблуждениях связанных с CSRF:
1. Подделка HTTP-запросов – новый тип уязвимостей.
Это далеко не так. Теоретические размышления на тему подделки источника сообщений датированы 1988 годом (http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), а практические примеры уязвимостей обсуждаются в Bugtraq как минимум с 2000 года (http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan). Сам термин введен Peter Watkins (http://www.securiteam.com/securitynews/5FP0C204KE.html) в 2001 году.
2. CSRF – это вариант Межсайтового выполнения сценариев (XSS).
Единственное сходство между CSRF и XSS, это использование в качестве вектора атаки клиентов Web-приложений (Client-Side Attack в терминологии WASC http://www.webappsec.org/projects/threat/). Уязвимости типа CSRF могут эксплуатироваться совместно с XSS или «редиректорами» (http://www.securitylab.ru/analytics/283136.php), но представляют собой отдельный класс уязвимостей.
3. Уязвимость CSRF мало распространена и достаточно сложна в использовании.
Данные, полученные компанией Positive Technologies в ходе работ по тестированию на проникновение и оценки защищенности Web-приложений показывают, что этой уязвимости подвержена большая часть Web-приложений. В отличие от других уязвимостей CSRF возникает не в результате ошибок программирования, а является нормальным поведением Web-сервера и браузера. Т.е. большинство сайтов, использующих стандартную архитектуру уязвимы «по умолчанию».
Пример использования
Давайте рассмотрим использование CSRF на примере. Предположим, существует некое Web-приложение, отправляющее сообщения электронной почты. Пользователь указывает адрес электронной почты и текст сообщения, нажимает кнопку Submit и сообщение от его адреса передается получателю.
http://img221.imageshack.us/img221/7114/1messagetw0.png
Отправка сообщения
Схема знакома по множеству сайтов и не вызывает никаких возражений. Однако указанное приложение с большой вероятности уязвимо для атак «Подделка HTTP-запроса». Для эксплуатации уязвимости злоумышленник может создать на своем сайте страницу содержащую ссылку на «изображение», после чего заставить пользователя перейти по ссылке на свой сайт (например, http://bh.ptsecurity.ru/xcheck/csrf.htm).
<img src="http://test.ptsecurity.ru/xcheck/send.asp?to=user@example.com&mess=Spam+The">
При обращении к странице браузер пользователя пытается загрузить изображение, для чего обращается к уязвимому приложению, т.е. оправляет сообщение электронной почты адресату, указанному в поле «to» запроса.
http://img95.imageshack.us/img95/4507/2senthb3.png
XSRF-атака
Обратите внимание, что браузер пользователя отправит сайту значение Cookie, т.е. запрос будет воспринят как исходящий от аутентифицированного пользователя. Для того чтобы заставить пользователя загрузить страницу, отправляющую запрос к уязвимому серверу, злоумышленник может использовать методы социальной инженерии, а также технические уязвимости, такие как XSS и ошибки в реализации функции перенаправления.
http://img181.imageshack.us/img181/9158/3csrfschemdm7.png
Логика работы XSRF
Таким образом, атака с использованием CSRF заключается в использовании браузера пользователя для передачи HTTP-запросов произвольным сайтам, а уязвимость – в отсутствии проверки источника HTTP-запроса. Приведенное в примере приложение использует HTTP-метод GET для передачи параметров, что упрощает жизнь злоумышленнику. Однако не стоит думать, что использование метода POST автоматически устраняет возможность проведения атак с подделкой HTTP-запроса. Страница на сервере злоумышленника может содержать готовую HTML-форму, автоматически отправляемую при просмотре страницы.
<html>
<body>
<form method=POST action="http://test.ptsecurity.ru/xcheck/postsend.asp"> Mail to:
<br><br>
<input type=text name=to value="user2spam@example.com"><br><br> Message:
<br><br>
<textarea width=20 name=mess>Spam The</textarea><br><br> <input type=submit id=doit> </form>
<script> document.getElementById("doit").click(); </script>
</body>
</html>
Для эксплуатации CSRF злоумышленнику совсем не обязательно иметь свой Web-сервер. Страница, инициирующая запрос может быть передана по электронной почте или другим способом.
В обзоре Billy Hoffman (http://www.gnucitizen.org/blog/javascript-remoting-dangers) приведены различные методы сетевого взаимодействия с помощью Javascript. Все они, включая XmlHttxmpquest (в некоторых ситуациях), могут быть задействованы для реализации атак CSRF.
Надеюсь, что сейчас читателю уже понятно основное отличие CSRF от XSS. В случае с XSS злоумышленник получает возможность доступа к DOM (Document Object Model) уязвимой страницы, как на чтение, так и на запись. При выполнении CSRF атакущий имеет возможность передать запрос серверу с помощью браузера пользователя, но получить и проанализировать ответ сервера, а тем более его заголовок (например, Cookie) уже не сможет. Соответственно, «Подделка HTTP-запросов» позволяет работать с приложением в режиме «только на запись», чего впрочем, вполне достаточно для выполнения реальных атак.
Основными целями CSRF-атак являются различные интерактивные Web-приложения, например системы электронной почты, форумы, CMS, интерфейсы удаленного управления сетевым оборудованием. Например, злоумышленник может отправлять сообщения от имени других пользователей, добавлять новые учетные записи, или изменять настройки маршрутизатора через Web-интерфейс.
http://img262.imageshack.us/img262/2241/4csrfui4.png
Пример эксплуатации XSRF в форуме
Остановимся подробнее на последнем – изменении настроек сетевых устройств. Автор уже упоминал об этой возможности (http://www.securitylab.ru/analytics/275562.php) по отношению к системам обнаружения беспроводных атак, но естественно, ими дело не ограничивается.
Пробиваем периметр
В декабре прошлого года компания Symantec опубликовала отчет (http://www.symantec.com/avcenter/reference/Driveby_Pharming.pdf) о «новой» атаке, под называнием «Drive-By Pharming», которая, по сути, является вариантом эксплуатации CSRF. Злоумышленник выполняет в браузере пользователя некий «волшебный» JavaScript, изменяющий настройки маршрутизатора, например устанавливающего новое значение DNS-сервера. Для выполнения этой атаки необходимо решить следующие задачи:
- сканирование портов с помощью JavaScript;
- определение типа Web-приложения (fingerprint);
- подбор пароля и аутентификация с помощью CSRF;
- изменение настроек узла с помощью атаки CSRF.
Техника сканирования определения доступности Web-сервера и его типа по с помощью javascript (http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html) проработана достаточно хорошо и сводится к динамическому созданию HTML-объектов (например, img src=), указывающие на различные внутренние URL (например, http://192.168.0.1/pageerror.gif). Если «картинка» была успешно загружена, то по тестируемому адресу расположен Web-сервер на базе Microsoft IIS. Если в ответ было получена ошибка 404, то порт открыт и на нем работает Web-сервер. В случае если был превышен таймаут – сервер отсутствует в сети или порт заблокирован на межсетевом экране. Ну и в остальных ситуациях – порт закрыт, но хост доступен (сервер вернул RST-пакет и браузер вернул ошибку до истечения таймаута). В некоторых ситуациях подобное сканирование портов из браузера пользователя может проводиться без использования JavaScript (http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html).
После определения типа устройства злоумышленник может попробовать заставить браузер пользователя сразу послать запрос на изменение настроек. Но такой запрос будет успешен только в случае, если браузер пользователя уже имеет активную аутентифицированную сессию с устройства. Иметь под рукой открытую страницу управления маршрутизатором - дурная привычка многих «продвинутых» пользователей.
Если же активной сессии с интерфейсом управления нет, злоумышленнику необходимо пройти аутентификацию. В случае если в устройстве реализована аутентификация на основе форм, никаких проблем не возникает. Используя CSRF в POST, серверу отправляются запрос на авторизацию, после чего с него загружается изображение (или страница) доступная только аутентифицированным пользователям. Если изображение было получено, то аутентификация прошла успешно, и можно приступать к дальнейшим действиям, в обратном случае – пробуем другой пароль.
В случае если в атакуемом устройстве реализована аутентификация по методу Basic, задача усложняется. Браузер Internet Explorer не поддерживает возможность указать имя пользователя и пароль в URL (например, http://user:рass@test.ptsecurity.ru). В связи с этим для выполнения Basic-аутентификации может использоваться метод с добавлением HTTP-заголовков с помощью Flash, описанный в статье Amit Clein (http://www.securitylab.ru/analytics/271169.php) . Однако этот метод подходит только для старых версий Flash, которые встречаются все реже и реже.
Но другие браузеры, например Firefox дают возможность указать имя пользователя и пароль в URL, и могут быть использованы для аутентификации на любом сервере, причем это можно сделать без генерации сообщения об ошибке в случае выбора неверного пароля.
Пример сценария для «тихой» аутентификации по методу Basic, из блога Stefan Esser (http://blog.php-security.org/archives/56-Bruteforcing-HTTP-Auth-in-Firefox-with-JavaScript.html) приведен ниже.
<html>
<head>
<title>Firefox HTTP Auth Bruteforcing</title>
<script> function okPW() { alert("User/Password Combination correct"); } function wrongPW() { alert("User/Password Combination is wrong"); } </script> <link rel="shortcut icon" href="http://user:pass@URL" type="image/x-icon">
</head>
<body> <img src="http://www.securitylab.ru/_article_images/2007/03/http://user:pass@URL" onLoad="okPW()" onError="wrongPW()">
</body>
</html>
http://img459.imageshack.us/img459/9418/5ffbasichu2.png
Аутентификация Basic в Firefox
В корпоративной среде, где зачастую используются механизмы SSO, например, на базе домена Active Directory и протоколов Kerberos и NTLM эксплуатация CSRF не требует дополнительных усилий. Браузер автоматически пройдет аутентификацию в контексте безопасности текущего пользователя.
После того как аутентификация была пройдена, злоумышленник с помощью JavaScript передать запрос, изменяющий произвольные настройки маршрутизатора, например адрес DNS-сервера.
Методы защиты
Первое, что приходит на ум, когда речь заходит о защите от CSRF – это проверка значения заголовка Referer. И действительно, поскольку подделка HTTP-запросов заключается в передаче запроса с третьего сайта, контроль исходной страницы, чей адрес автоматически добавляется браузером в заголовки запроса, может решить проблему.
Однако этот механизм имеет ряд недостатков. Во-первых – перед разработчиком встает вопрос об обработке запросов, не имеющих заголовка Referer как такового. Многие из персональных межсетевых экранов и анонимизирующих proxy-серверов вырезают Referer, как потенциально небезопасный заголовок. Соответственно, если сервер будет игнорировать подобные запросы, группа наиболее «параноидально» настроенных граждан не смогут с ним работать.
Во-вторых, в некоторых ситуациях заголовок Referer может быть подделан, например, с помощью уже упоминавшегося трюка с Flash. Если пользователь применяет IE 6.0, то содержимое заголовка запроса может быть модифицировано c использованием ошибки в реализации XmlHttxmpquest. Уязвимость заключается в возможности использования символов перевода строки в имени HTTP-метода, что позволяет изменять заголовки и даже внедрять дополнительный запрос. Эта уязвимость была обнаружена Amit Clein (http://www.securityfocus.com/archive/1/411585) в 2005 году и снова открыта в 2007. Ограничением этого метода является то, что он работает только в случае наличия между пользователем и сервером HTTP-Proxy или размещения серверов на одном IP-адресе, но с разными доменными именами.
Другой распространенный метод – добавление уникального параметра к каждому запросу, который затем проверяется сервером. Параметр может добавляться к URL при использовании GET запроса как например, в Google Desktop (http://www.watchfire.com/Fresources/Overtaking-Google-Desktop.pdf) или в виде спрятанного параметра формы, при использовании POST. Значение параметра может быть произвольным, главное, чтобы злоумышленник не мог его предсказать, например – значение сессии пользователя.
http://img132.imageshack.us/img132/6065/6bitrxt6.png
Защита от XSRF в Bitrix
Для быстрого добавления функции проверки CSRF в свое приложение можно воспользоваться следующим подходом:
1. Добавлять в каждую генерируемую страницу небольшой JavaScript, дописывающий во все формы дополнительный скрытый параметр, которому присваивается значение Cookie.
2. Проверять на сервере, что переданные клиентом с помощью метода POST данные содержат значение, равное текущему значению Cookie.
Пример подобного клиентского сценария приведен ниже:
<script>
strCookie = document.cookie;
for (i=0;i<document.forms.length;i++)
{
var newTextField = document.createElement('input');
newTextField.setAttribute('type','hidden');
newTextField.setAttribute('name','session');
newTextField.value=strCookie; document.forms[i].appendChild(newTextField);
}
</script>
Дальнейшим развитием этого подхода является сохранение идентификатора сессии не в Cookie, а в качестве скрытого параметра формы (например, VIEWSTATE).
В качестве метода противодействия CSRF могут использоваться различные варианты тестов Тьюринга, например, хорошо известные всем изображения - CAPTCHA. Другим популярным вариантом является необходимость ввода пользовательского пароля при изменении критичных настроек.
http://img178.imageshack.us/img178/61/7maillp7.png
Защита от XSRF в mail.ru
Таким образом, Cross-Site Request Forgery являются атакой, направленной на клиента Web-приложения и использующей недостаточную проверку источника HTTP-запроса. Для защиты от подобных атак может использоваться дополнительный контроль источника запроса на основе заголовка Referer или дополнительного «случайного» параметра.
Сергей Гордейчик
gоrdey @ ptsеcurity com
Источник (http://www.securitylab.ru/analytics/292473.php)