Библиотека сайта rus-linux.net
Безопасная эксплуатация Apache, часть 3: атаки на основе создания межсайтовых запросов (XSRF)
Оригинал: Securing Apache, Part 3: Cross-Site Request Forgery Attacks (XSRF)
Автор: Arpit Bajpai
Дата публикации: 1 Ноября 2010 г.
Перевод: А.Панин
Дата перевода: 7 Января 2013 г.
Данная серия статей предназначена для информирования экспертов в области безопасности, системных администраторов и всех тех, кто сталкивается с вопросами безопасности веб-приложений, а в данной третьей статье серии, после рассмотрения SQL-инъекций и XSS-атак, начинается обсуждение вопросов защиты веб-приложений от атак на основе создания межсайтовых запросов. Я еще раз напоминаю, что ни коллектив журнала LFY, ни я не ставим своей целью научить вас атаковать серверы. Наоборот, описание техник проведения атак приводится для того, чтобы дать вам необходимые знания, которые могут пригодиться при защите вашей инфраструктуры.
Атаки на основе создания межсайтовых запросов (CSRF, также известные, как XSRF, атаки одного клика, атаки перекрытия сессий, атаки запутанного посредничества, атаки с использованием трояна на стороне клиента, атаки враждебного связывания, автоматизированные атаки или серфинг-атаки) реализуются на стороне клиента при помощи эксплуатации неявных механизмов аутентификации для принуждения пользователя к выполнению нежелательных действий после аутентификации с помощью веб-приложения. CSRF-атаки являются опасной угрозой безопасности веб-приложений, которой невозможно избежать, а постоянная 5 позиция в рейтинге 10 самых опасных угроз веб-приложениям по версии консорциума OWASP за последние 3 года только подчеркивает этот факт.
Простейшие приемы социальной инженерии (например, с применением электронной почты или службы мгновенных сообщений) - это все что нужно для того, чтобы заманить жертву атаки в ловушку и заставить невольно выполнять указанные взломщиком действия. В случае, если CSRF-атака против обычного пользователя успешно завершается, его данные и операции компрометируются. Если же атака проводится против учетной записи администратора, может быть скомпрометировано все веб-приложение.
Сама аббревиатура CSRF говорит о том, что атака проводится при использовании межсайтового запроса; слово "создание" используется потому, что этот запрос невидим для пользователя. Под межсайтовым запросом понимается ситуация, при которой страница, загруженная с одного веб-сайта отправляет запрос другому сайту на получение ресурсов, являющихся частью этой страницы (например, таких, как изображения). Хотя вредоносный сайт и может содержать HTML-код для этих целей на своих страницах, такие межсайтовые запросы могут проводиться также при просмотре систем сообщений, форумов или сайтов социальных сетей (например), где пользователям разрешается размещать изображения из разных источников - в этом случае изображения будут размещаться на других сайтах.
- Жертва атаки работает в рамках активной сессии на целевом сайте.
- Жертва атаки прошла аутентификацию при помощи скрытых механизмов аутентификации (таких, как куки или HTTP-аутентификация) на целевом сайте.
Главной целью проведения CSRF-атаки является выполнение действий на целевом сайте с привилегиями жертвы атаки в рамках действительной сессии аутентификации. Ключевым требованием для проведения атаки является преимущественный доступ и знание корректного URL веб-приложения взломщиком. В рамках типичной CSRF-атаки взломщик создает скрытый HTTP-запрос в веб-браузере жертвы атаки, который исполняется в контексте аутентификации без информирования пользователя.
Три возможных сценария реализации CSRF-атаки
Рассмотрим три возможных сценария, при которых возможна реализация CSRF-атаки, а также процесс реализации атаки.
Сценарий 1
Предположим, что жертва атаки произвела вход в систему онлайн-банкинга при помощи своей учетной записи и использует функцию перевода средств. Сайт банка использует куки (скрытый механизм аутентификации) для аутентификации вошедших в систему пользователей в рамках сессий. После заполнения формы для перевода средств при нажатии кнопки "Отправить запрос"/"OK"/"Завершить перевод" веб-браузер жертвы атаки отправляет HTTP-запрос веб-серверу банка для осуществления перевода средств. Ниже представлен образец того, как примерно будет выглядеть HTTP POST-запрос:
При использовании HTTP GET-запроса, он будет выглядеть примерно следующим образом:
| Примечание: взломщик может получить примеры запросов или ответов HTTP, передающиеся от или к веб-серверу разными путями: воспользовавшись услугами таких сайтов, как web-sniffer.net и http-sniffer.com или используя сниффер в своей локальной сети во время осуществления запросов к сайту банка. Исследование захваченных запросов и ответов позволяет вычислить формат URL данного веб-приложения. |
Теперь представим, что жертва атаки, все еще работая со свей учетной записью на сайте онлайн-банкинга, открывает еще одно окно ли вкладку в том же веб-браузере с вредоносным сайтом (давайте назовем его www.attacker.com). Это могло произойти из-за перехода по ссылке от злоумышленника, отправленной с помощью системы мгновенных сообщений или электронной почты. Эта ссылка могла привести жертву атаки на страницу http://www.attacker.com/checkthisout.html, содержащую следующий вредоносный HTML-код:
Когда браузер жертвы атаки загружает страницу, он также пытается показать заданную картинку с шириной и длиной в ноль пикселей (то есть невидимую), выполняя запрос ресурса с заданного в атрибуте src URL. Так как клиент банка все еще работает со своей учетной записью на сайте банка, средства в размере 5000 будут переведены со счета номер 35367021 на счет номер 48412334, который может принадлежать взломщику. Сайт банка расценивает этот запрос как полностью корректный, поскольку данные из кук указывают на то, что пользователь прошел аутентификацию, предоставив корректные данные! Описанная выше атака схематично изображена на Рисунке 1.
Рисунок 1: CSRF-атака при помощи GET-запроса (щелкните для увеличения)
Для того, чтобы находчивые пользователи или кто-либо, случайно столкнувшийся с CSRF-атаками с использованием ссылки на изображение, не начали беспокоиться, строка URL может быть преобразована для создания иллюзии безопасного HTTP-запроса. Взломщик может сделать ее похожей на корректную строку URL изображения, такую, как <img src="https://www.attacker.com/picture1.gif" width="0" height="0" />. В данном случае во время приема запроса файла picture1.gif на сайте attacker.com используется механизм переадресации HTTP для открытия другого URL пользовательским браузером. При этом производится изменение состояния веб-приложения - аналогично URL для перевода средств из данного сценария.
Метод атаки, описанный выше, может использоваться тогда, когда веб-приложение использует метод HTTP GET для отправки запросов. Если вместо него используется метод HTTP POST, взломщик может использовать скрытый элемент iframe, содержащий HTTP-форму со сценарием JavaScript для отправки запроса на сайт банка, примерный фрагмент кода которого представлен ниже:
CSRF-атака с использованием метода HTTP POST обобщена на Рисунке 2.
Рисунок 2: CSRF-атака с использованием метода HTTP POST
Пожалуйста учтите, что данный сценарий использовался только для подробного объяснения принципа работы CSRF-атаки и того, что банк не приложил усилий для защиты сайта от данного типа атаки. Я повторяю, что вы не должны пытаться использовать эту последовательность действий в отношении любых публичных серверов.
Сценарий 2
Другой сценарий CSRF-атаки позволяет выполнять действия с помощью веб-интерфейса для управления межсетевым экраном. В данной атаке также используются данные о сессиях из кук. Давайте предположим, что веб-приложение для управления межсетевым экраном позволяет прошедшему аутентификацию пользователю удалять правило, заданное его порядковым номером, а также удалять все правила при вводе пользователем символа "*". Например, корректный URL для удаления одного правила с номером 5 будет выглядеть следующим образом: http://www.example.com/firemange/delete?rule=5.
В этом случае вредоносный HTML-код для осуществления CSRF-атаки с использованием HTTP GET-запроса будет выглядеть следующим образом:
Сценарий 3
Маршрутизаторы для домашнего использования, например, популярные DSL-маршрутизаторы поставляются с заданным IP-адресом LAN-интерфейса (192.168.0.1), который не изменяется большинством пользователей. Таким образом, адрес узла для формирования URL известен в большинстве случаев. Взломщики знакомы с принципом работы и строками URL для популярных моделей маршрутизаторов и в том случае, если им удается использовать социальную инженерию для принуждения пользователя к переходу по вредоносной ссылке, они могут (например) активировать веб-интерфейс для удаленного управления на порту 8080, что позволяет управлять маршрутизатором с любого компьютера в Интернет.
Вредоносная веб-страница может содержать следующий HTML-код:
Взломщик может также сменить имя стандартной учетной записи маршрутизатора и даже получить доступ к сетевым принтерам - поэтому, если вы используете свой домашний DSL-маршрутизатор со стандартными настройками, займитесь сменой заданного IP-адреса и стандартных паролей прямо сейчас!
Используя известные строки URL веб-приложений, взломщик может также сбросить ваши пароли для учетных записей веб-приложений, провести манипуляции с веб-приложением для работы с корпоративной почтой, удалить или модифицировать учетные записи веб-приложений. Атаки на основе создания межсайтовых запросов представляют большую опасность и не терпят несерьезного отношения.
Различия между XSS и CSRF-атаками
Хотя на первый взгляд CSRF-атаки очень похожи на атаки на основе межсайтового скриптинга (XSS), они отличаются своими целями. В то время, как целью XSS-атаки является вставка активного кода в HTML-документ либо для эксплуатации уязвимостей среды исполнения сценариев на стороне клиента, либо для отправки важной информации (такой, как данные из кук для аутентификации в рамках сессии) на неизвестный сайт злоумышленника, целью CSRF-атаки является выполнение нежелательных для пользователя действий с помощью веб-сайта, на котором он имеет учетную запись и с которым он работал ранее.
Более того, там, где с помощью XSS-атаки ищут возможность для похищения данных из кук для манипуляции пользовательской учетной записью, с помощью CSRF-атаки ищут возможность использования пользовательских кук для выполнения действий без информирования и получения согласия пользователя. В случае XSS-атак используется доверие, оказываемое пользователем веб-сайту, а в случае CSRF-атак - доверие веб-сайта своему пользователю.
Типы CSRF-атак
CSRF-атаки могут быть разделены на две основные категории - отраженные и хранимые/локальные.
Отраженные CSRF-атаки
При отраженной CSRF-атаке взломщик использует систему вне приложения для доставки жертве атаки вредоносной ссылки или кода. Для этого может использоваться блог, сообщение электронной почты, мгновенное сообщение, сообщение на форуме или даже флаер в публичном месте со строкой URL, которую жертва атаки должна ввести самостоятельно.
Отраженыые атаки должны периодически завершаться неудачно, так как пользователи могут в данной момент не работать в рамках своей учетной записи на ресурсе, против которого направлена атака. След от реализации данной атаки должен находиться у взломщика под контролем и может быть удален как только атака будет завершена. Три сценария атак, рассмотренные выше, являются примерами отраженных CSRF-атак.
Локальные/хранимые CSRF-атаки
При локальных/хранимых CSRF-атаках взломщик может использовать приложение для доставки жертве атаки вредоносной ссылки ли других данных, которые приведут к выполнению браузером жертвы атаки контролируемых взломщиком операций с приложением. Хранимые CSRF-уязвимости эксплуатируются с большей вероятностью, так как пользователь, получающий вредоносные данные практически всегда работает с приложением в рамках своей учетной записи.
Хранимые CSRF-атаки оставляют после себя более очевидный след, который может привести к взломщику, поскольку изначальный вредоносный HTTP-запрос реализуется на атакуемом веб-сайте. В качестве примеров могут быть приведены форумы и сайты социальных сетей, на которых пользователям разрешается размещать изображения с других сайтов. Уязвимости, используемые при этих атаках, сложнее найти и устранить.
Почему CSRF-атаки возможны
- Неявная аутентификация
- Явная аутентификация
Неявная аутентификация с помощью веб-браузеров
- HTTP-аутентификация: При использовании этого механизма веб-сервер может запрашивать аутентификационную информацию у браузера с целью ограничения доступа к определенным веб-страницам. При использовании трех доступных методов (basic, digest и NTLM) процесс начальной аутентификации проходит одни и те же основные этапы. Рисунок 3 иллюстрирует упрощенную версию данного процесса аутентификации. Если клиент осуществляет последующие запросы ресурсов с ограниченным доступом, находящихся в той же области ограничения доступа, браузер автоматически добавляет аутентификационные данные к запросу.
Рисунок 3: Типичная HTTP-аутентификация - Куки: Технология кук веб-браузера позволяет осуществлять постоянное хранение данных на стороне клиента и обычно используется современными веб-приложениями для храниения аутентификационных данных. После успешной процедуры входа в систему с использованием учетной записи, сервер отправляет куки клиенту. Каждый последующий HTTP-запрос, содержащий данные из кук, автоматически считается аутентифицированным. Типичный аутентификационный процесс с использованием кук показан на Рисунке 4.
Рисунок 4: Типичный процесс аутентификации с использованием кук - SSL-аутентификация на стороне клиента: Протокол заищенных сокетов (SSL) и пришедший ему на смену протокол безопасности транспортного уровня (TLS) позволяют осуществлять передачу данных между веб-браузером и веб-сервером с аутентификацией на основе криптографических алгоритмов. Для аутентификации в данном случае используются схемы с сертификатами X.509 и цифровыми подписями.
У этих трех механизмов есть общая черта: после успешной начальной аутентификации при осуществлении запросов происходит автоматическая передача аутентификационных данных без получения разрешения от пользователя - это и делает веб-приложения, использующие эти механизмы, уязвимыми к CSRF-атакам.
Неявная аутентификация на основе IP-адреса
Это особенный вариант неявной аутентификации, обычно встречающийся в сетях интранет. В данном случае аутентификация происходит на основе IP- (или MAC-) адресов, с которых осуществляются запросы к веб-приложению. На Рисунке 5 показан типичный механизм аутентификации на основе IP-адресов, при котором только пользователи из сети интранет имеют доступ к интранет-серверу, а запросы со всех других адресов отклоняются.
Рисунок 5: Типичный процесс аутентификации на основе IP-адресов
Более безопасная явная аутентификация
- Перезапись URL, при использовании которой идентификаторы сессий добавляются к URL для каждого запроса, отправляемого серверу; URL генерируется веб-приложением или веб-сервером, поэтому от веб-браузера не требуется добавления аутентификационных данных к запросам.
- Идентификаторы сессий на основе форм, при использовании которых гиперссылки заменяются на HTML-формы, содержащие идентификаторы сессий в скрытых полях.
Хотя схемы явной аутентификации и не уязвимы для CSRF-атак, они имеют ряд других недостатков, о которых мы поговорим позднее.
Главной причиной, по которой становятся возможными CSRF-атаки является то, что веб-приложения, использующие неявные механизмы аутентификации, не проверяют факта исполнения запросов изменения состояния в рамках веб-приложения. Благодаря неявной аутентификации пользователя взломщик может без лишних сложностей контролировать пользовательскую сессию.
Другим лежащим в основе CSRF-атак фактором является использование приложением известных строк URL и действий форм, которые возможно повторить.
| Мифы | Факты |
| CSRF-атаки являются всего лишь частным случаем XSS-атак. | Уязвимости XSRF отличаются от XSS и предполагают различные методы защиты. Методы защиты от XSS-уязвимостей не предотвратят XSRF-атак, хотя преимущественная защита от XSS-атак и является особо важной задачей. |
| Приложения не уязвимы для CSRF-атак в случае использования многостраничных форм для выполнения действий. | Хотя многостраничные формы и затрудняют эксплуатацию уязвимостей, на самом деле взломщики могут эксплуатировать их. Взломщики часто используют множество IFRAME-ов для создания эксплоитов для многостраничных форм. |
| Можно предотвратить CSRF-атаки, используя для всех важных запросов метод POST и запретив использование метода GET. | Хотя организация атак при использовании метода POST и сложнее, их конечно же можно провести аналогично примеру в Сценарии 1. Использование метода POST вместо GET может защитить только от локальных CSRF-атак; выполнение POST-запросов все также будет возможно с помощью скрытых элементов IFRAME на сторонних веб-страницах. С помощью форм можно ввести пользователю в заблуждение о том, какие данные и куда отправляются, а с помощью сценариев возможна автоматизация отправки данных. JavaScript поддерживает отправку данных форм с использованием метода POST. |
| CSRF-атаки могут быть предотвращены при фильтрации данных на основании значения параметра "referrer" из заголовков запросов. | Этот метод очень ненадежен, так как взломщики могут просто заблокировать отправку параметра "referrer" в заголовке при помощью определенных дополнений для браузера и Flash. Некоторые браузеры также исключают параметр "referrer" при использовании SSL-соединения. Более того, многие межсетевые экраны и антивирусные программы отбрасывают этот параметр в режиме работы по умолчанию без информирования пользователя. Тем не менее, получение информации о источнике запроса явлется еще одной ступенью к реализации безопасной работы системы. |
| Установка принудительного использования браузером технологии "Same Origin Policy (SOP)" позволяет предотвратить CSRF-атаки. | Браузеры, поддерживающие технологию SOP, будут предотвращать попытки сценариев получить доступ к модели DOM страницы, загруженной с другого домена, или доступ к кукам, полученным с других доменов. Как бы то ни было, данная технология не предотвращает отправку запросов к другим доменам с использованием сценариев. Более того, когда сценарий отправляет запрос другому домену (или когда атрибут SRC тэга IMG ссылается на другой домен), браузер выполнит запрос и также отправит имеющиеся куки для домена вместе с запросом.(Обратитесь к примечанию о технологии SOP ниже). |
| Same Origin Policy (SOP): Веб-браузеры используют модель безопасности "Same Origin Policy (SOP)" с целью введения некоторых ограничений доступа для веб-приложений. С помощью SOP производится идентификация каждого веб-сайта на основе его происхождения, которое определяется как уникальная комбинация протокола, домена и номера порта, а на основе происхождения создается контекст для каждой записи. Два ресурса могут считаться имеющими одинаковое происхождение только если все значения приведенных выше параметров идентичны. |
Сложные методы реализации CSRF-атак
Следующие методы реализации CSRF-атак были обнаружены в течение нескольких последних лет.
Обход защиты от CSRF-атак при помощи технологии "click-jacking"
Эта недавно появившаяся техника может использоваться для обхода защиты от CSRF-атак и отправки с использованием метода POST форм с данными взломщика с применением технологии "click-jacking". (Обратитесь к примечанию о технологии "click-jacking" ниже для получения более подробной информации о ней.) Лучшим примером использования этой техники является эксплуатация уязвимостей в системах обновления адресов электронной почты. Такие системы часто используются в веб-приложениях. В ходе атаки взломщик заставляет жертву атаки изменить свой адрес электронной почты на адрес, принадлежащий взломщику, а после этого взломщик может получить доступ к учетной записи пользователя, выполнив сброс пароля.
Эта атака может быть осуществлена даже в том случае, когда веб-приложение защищено от CSRF-атак. Детальное описание этого процесса приведено в данном посте из блога.
| Click-jacking является видом атаки, использующим встраиваемые объекты на веб-странице, созданной злоумышленником. Используя содержимое фрейма наряду с апплетами Flash, Silverlight или Java, взломщик размещает скрытую или невидимую кнопку под указателем мыши, поэтому в любой момент при использовании любого элемента страницы пользователем, он также производит действие с невидимым веб-сайтом, который может содержать вредоносный код. В ходе атаки также могут использоваться возможности технологий динамического HTML и CSS (каскадных таблиц стилей) для лучшей маскировки. |
Разница между CSRF-атаками и технологией "click-jacking" состоит в том, что при CSRF-атаке используется браузер (автоматически по URL загружается код для изменения состояния) без необходимости запуска кода жертвой атаки, в то время, как при использовании технологии "click-jacking" пользователь взаимодействует с каким-либо объектом, но действие "похищается" путем размещения промежуточного слоя между пользовательским указателем и элементом страницы, выполняющим корректное действие.
Использование XSS-атак для обхода защиты от CSRF-атак
Данная техника применима для веб-сайтов с защитой от CSRF-атак, имеющих страницы с XSS-уязвимостями. Большим заблуждением является мнение о том, что защита от CSRF-атак может также защитить приложение от XSS-атак. Используя XSS-атаки, взломщики могут преодолеть защиту от CSRF-атак и без проблем использовать любое действие, совершаемое с приложением. Взломщики просто читают генерируемый сайтом идентификатор из ответа сайта и добавляют этот идентификатор в создаваемый запрос. Одним из примеров использования этой техники является случай, когда взломщики эксплуатируют уязвимость веб-сайта для добавления пользователя с привилегиями администратора, при этом веб-сайт имеет систему защиты от CSRF-атак.
Ссылка на интересное обсуждение данной техники атаки (с примерами кода) доступна в разделе дополнительных ресурсов в конце статьи. Пожалуйста, уделите ей немного времени. В частности, по ссылке описывается случай использования XSS-уязвимсти червем Samy, преодолевшим защиту от CSRF-атак социальной сети MySpace в 2005 году и инфицировавшим более миллиона пользовательских учетных записей всего за 20 часов после запуска.
Атаки на сети интранет
В ходе атак на сети интранет используются CSRF-атаки в рамках неявных схем аутентификации на основе IP-адресов. Большинство серверов в сетях интранет уязвимо для данного типа атак. Тот факт, что большинство серверов в сетях интранет продолжают использовать стандартные пароли, работать без установки обновлений безопасности и опираться исключительн на межсетевой экран как на средство защиты от внешних атак, обуславливает рост количества SCRF-уязвимостей в этих сетях. Атака на сеть интранет может быть проведена с помощью вредоносного сценария JavaScript при наличии доступа за границу межсетевого экрана; поскольку сценарии JavaScript не являются зависимыми от операционной системы узлов и веб-браузеров, их применению сложно противостоять.
Одним из примеров CSRF-атаки с использованием сценариев JavaScript является сканирование портов веб-сервера в сети интранет. В рамках сценария JavaScript создается локальный (действующий в сети интранет) URL, содержащий IP-адрес и порт, которые должны быть исследованы. После этого к сценарию добавляется элемент в состав веб-страницы (такой, как изображение, IFRAME или удаленный сценарий), доступный по URL.
Также при помощи функций ограничения времени JavaScript и обработчиков событий, таких, как OnLoad и OnError, сценарий получает возможность определения, доступен ли узел и открыт ли исследуемый порт. Если время ожидания заканчивается, узел, вероятнее всего, не доступен. Событие OnLoad говорит о том, что на узле, вероятно, работает веб-сервер, а событие OnError указывает на то, что узел присутствует в сети, но порт закрыт. Типичный сценарий атаки показан на Рисунке 6.
Рисунок 6: Сканирование портов сервера в сети интранет
<SCRIPT SRC="http://211.224.196.1/"></SCRIPT>
Как только пользователь посещает данную страницу, информация о существовании веб-сервера отправляется взломщику в форме отчетов об ошибках. Кроме этого, взломщик может исследовать приложения, маршрутизаторы, сетевые устройства, а также устанавливать с помощью перебора номеров портов позицию в сети серверов, работающих по протоколу HTTPS или используемых для разработки.
Защита от CSRF-атак
Следующие полезные советы для пользователей и разработчиков могут значительно помочь в работе по нейтрализации CSRF-атак.
- Прекращайте работу со своей учетной записью в рамках важного веб-приложения сразу же после того, ка вы закончили работу с приложением или совершили транзакции. Не открывайте любые сайты, которым вы не доверяете одновременно с выполнением действий со своей учетной записью на важном сайте. Если вам все таки необходимо по какой-либо причине сделать это, используйте отдельный браузер для недоверенных сайтов.
- Используйте Mozilla Firefox с дополнением NoScript, позволяющим использовать сценарии JavaScript, апплеты Java и другие исполняемые элементы страниц только для доменов, которым вы доверяете и которые вы выбрали. Это один из лучших методов защиты от атак на основе XSS, CSRF и click-jacking. Также старайтесь использовать дополнение CSFire, защищающее вас от CSRF-атак и других опасных или вредоносных междоменных запросов. Дополнение CSFire позволяет убирать из отправляемых запросов аутентификационную информацию (куки и заголовки аутентификации).
- Используйте несколько браузеров и разделяйте просматриваемые сайты на категории доверенных, важных сайтов или приложений и недоверенных, менее важных сайтов и приложений. Например, используйте Firefox с установленными дополнениями NoScript и Adblock Plus (ABP) для рабты с доверенными и важными сайтами и приложениями. В списке дополнения NoScript разрешите исполнение сценариев на сайтах, которым вы доверяете для того, чтобы на них работали сценарии JavaScript. Настройте дополнение ABP для блокировки известных вредоносных сайтов; для создания списка таких сайтов используйте URL для автоматической настройки, приведенный в конце данного поста из блога. Для посещения других (недоверенных) сайтов установите другой браузер, такой, как Google Chrome, Chromium или Opera. Если вы не уверены насчет ссылок на доверенные сайты, полученных вне этих сайтов (например, кто-либо прислал по электронной почте ссылку на учетную запись для сервиса GMail, почту на котором вы просматриваете при помощи браузера Firefox), то вместо посещения данной ссылки при помощи Firefox, перетащите эту ссылку из окна Firefox в строку вкладок Chrome/Chromium (или скопируйте и вставьте ее) для того, чтобы она открылась в новой вкладке браузера Chromium. Так как между браузерами передается исключительно строки URL, а все идентификаторы неявной аутентификации остаются в браузере Firefox, эта методика является наиболее безопасной.
- Регулярное удаление кук с длительным периодом хранения (тех кук, которые становятся недействительными после очень длительного промежутка времени) также помогает снизить опасность атаки.
- Если это возможно, не храните имена пользователей и пароли в менеджере паролей браузера (например, прочитайте эту статью LWN).
- Лучшим средством защиты от CSRF-атак является генерация идентификаторов с непредсказуемым значением, представленных в виде данных, которые сервер может использовать для установления корректности запроса и которые невозможно предугадать для взломщика. Например, важный запрос может содержать идентификатор пользовательских данных сессии, различный для каждого пользователя. Также для большей безопасности следует добавлять к идентификатору отметку времени для ограничения возможности его подбора, таким образом, как показано в примере POST-запроса ниже: Используемые идентификаторы также должны быть очень криптостойкими.
- Ограничивайте время, в течение которого пользовательская сессия считается действительной. Вводя ограничение времени активности сессии, вы снижаете шансы проведения CSRF-атак.
- Повторная проверка пароля должна иметь приоритет перед единой системой входа. При использовании этого метода пользователи должны повторно вводить пароль при доступе к чрезвычайно важным функциям.
- Переход к использованию механизма перезаписи URL не рекомендуется потому, что в случае содержания идентификаторов сессий в строках URL, они могут быть получены из журналов прокси-серверов или параметра "refferer" заголовка. Более того, они также мало полезны при локальных CSRF-атаках, поскольку все строки URL от веб-приложения содержат идентификатор.
- Не полагайтесь (исключительно) на проверку параметра "referrer" заголовка, так как существуют техники создания HTTP-запросов без использования этого параметра.
- Для защиты от локальных/хранимых атак вам следует зеркалировать весь контент со сторонних ресурсов и не позволять использовать произвольные строки URL в вашем приложении. Более того, локальные атаки могут быть сведены на нет если вы всего лишь будете использовать изображения с вашего сервера (актуально для социальных сетей и форумов) и не будете позволять пользователям хранить произвольные данные на ваших серверах.
- При создании системы защиты от CSRF-атак следует позаботиться о устранении XSS-уязвимостей.
- Установите столько преград на пути взломщика, сколько возможно, включая такие средства, как настройка сообщений об ошибках, проверка параметра "referrer" в заголовках HTTP и экраны для веб-приложений.
- Используйте систему защиты CAPTCHA, особенно для важных транзакций, чтобы убедиться в том, что на другом конце находится человек, а не автоматизированная система.
- Защищайте веб-сайты в сетях интранет, устанавливайте обновления и патчи безопасности и меняйте стандартные пароли.
Инструменты
- OWASP CSRF tester: Это JavaEE-фильтр, реализующий модель синхронизации с использованием идентификаторов для сведения на нет риска проведения CSRF-атак. Обратитесь к документации, расположенной здесь. Реализация данного инструмента защиты от CSRF-атак с использованием языка PHP доступна здесь, а реализация с использованием .NET - здесь.
- RequestRodeo является реализацией HTTP-прокси с использованием языка Python, фреймворка Twisted, библиотек OpenSSL и SQLite. Он защищает пользователя от CSRF-атак. Вы можете найти его здесь.
Для получения более подробной информации о CSRF-атаках и методах защиты от них, не забудьте обратиться к разделу дополнительных ресурсов ниже. Мы поговорим о других опасных атаках на веб-приложения и Apache в следующей статье.
Всегда помните: нужно знать все о взломе, не не заниматься им.
- Документ с названием Using XSS to Bypass XSRF Protection (Использование XSS-атак для обхода защиты от XSRF-атак)
- Проект secologic
- Шпаргалка по предотвращению CSRF-атак
- Ресурс whitehatsec.com содержит ценную информацию о XSS-атаках, CSRF-атаках и других типах атак.
Продолжение серии: "Безопасная эксплуатация Apache, часть 4: атаки на основе межсайтовой трассировки (XST) и межсайтовых манипуляций с историей (XSHM)"