Атака csrf

Введение

Laravel позволяет легко защитить ваше приложение от атак с подделкой межсайтовых запросов (CSRF). Подделка межсайтовых запросов — тип атаки на сайты, при котором несанкционированные команды выполняются от имени аутентифицированного пользователя.

Laravel автоматически генерирует CSRF-токен для каждой активной пользовательской сессии в приложении. Этот токен используется для проверки того, что именно авторизованный пользователь делает запрос в приложение.

При определении каждой HTML-формы вы должны включать в неё скрытое поле CSRF-токена, чтобы посредник CSRF-защиты мог проверить запрос. Вы можете использовать Blade-директиву для генерирования поля токена:

Посредник , входящий в группу посредников , автоматически проверяет совпадение токена в данных запроса с токеном, хранящимся в сессии.

CSRF токены и JavaScript

При создании приложений, работающих на JavaScript, удобно, чтобы собственная JavaScript HTTP-библиотека автоматически прикрепляла CSRF-токен к каждому исходящему запросу. По умолчанию библиотека Axios настроена так, что передаёт заголовок , используя значение зашифрованной куки (см. файл ). Если вы не используете эту библиотеку, то вам нужно будет вручную настраивать это поведение для своего приложения.

Referer-based defenses against CSRF

Aside from defenses that employ CSRF tokens, some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks, normally by verifying that the request originated from the application’s own domain. This approach is generally less effective and is often subject to bypasses.

Referer header

The HTTP Referer header (which is inadvertently misspelled in the HTTP specification) is an optional request header that contains the URL of the web page that linked to the resource that is being requested. It is generally added automatically by browsers when a user triggers an HTTP request, including by clicking a link or submitting a form. Various methods exist that allow the linking page to withhold or modify the value of the Referer header. This is often done for privacy reasons.

Validation of Referer depends on header being present

Some applications validate the Referer header when it is present in requests but skip the validation if the header is omitted.

In this situation, an attacker can craft their CSRF exploit in a way that causes the victim user’s browser to drop the Referer header in the resulting request. There are various ways to achieve this, but the easiest is using a META tag within the HTML page that hosts the CSRF attack:

LAB
CSRF where Referer validation depends on header being present

Validation of Referer can be circumvented

Some applications validate the Referer header in a naive way that can be bypassed. For example, if the application simply validates that the Referer contains its own domain name, then the attacker can place the required value elsewhere in the URL:

If the application validates that the domain in the Referer starts with the expected value, then the attacker can place this as a subdomain of their own domain:

LAB
CSRF with broken Referer validation

Инструменты сканирования безопасности и XSRF

Сканеры безопасности часто сообщают о XSRF, но это не обязательно означает наличие реальной уязвимости. Сканер не может отличить чувствительный запрос от нечувствительного. Однако если на сайте реализован всеобъемлющий метод, описанный в этой статье, сканер не найдет никаких проблем с XSRF.

Изменение в соответствии с этой статьей всех запросов, а не только чувствительных, поможет уберечь неопытных разработчиков от возникновения описанной проблемы в будущем.

Похожие темы

• Оригинал статьи: Prevent cross-site request forgery: Know the hidden danger in your browser tabs (EN).
• Посетите блог Security на developerWorks, где можно найти самые последние руководства с инструкциями, статьи и видеоматериалы, посвященные безопасности.
• Посетите сообщество Security на developerWorks, в библиотеке ресурсов которого можно найти руководства с инструкциями, статьи, видео и демонстрационные материалы.
• Подпишитесь на еженедельную рассылку Security On developerWorks newsletter, чтобы получать самые свежие новости, касающиеся безопасности.
• Следите за @dWSecurity в Твиттере, чтобы получать обновления раздела Security на developerWorks в режиме реального времени.
• Загрузите с Web-сайта developerWorks ознакомительную версию IBM Security AppScan Standard.

история

CSRF уязвимости известны и в некоторых случаях эксплуатации с 2001 года Поскольку осуществляется от пользователя IP — адрес , некоторые журналы веб — сайта может не иметь доказательства CSRF. Эксплойты занижены, по крайней мере публично, и по состоянию на 2007 г. было несколько хорошо документированных примеров:

• Netflix веб — сайт в 2006 году были многочисленные уязвимости к CSRF, которые могли бы позволить атакующему выполнять такие действия, как добавление DVD в аренду очереди жертвы, изменить адрес доставки на счету, или изменения учетных данных для входа жертвы, чтобы полностью скомпрометировать счет,
• Онлайн — банкинг веб — приложение ING Direct была уязвима для атак CSRF , что позволило незаконных денежных переводов.
• Популярное видео веб — сайт YouTube был также уязвим для CSRF в 2008 году, и это позволило любому злоумышленнику выполнить практически все действия любого пользователя.
• McAfee также уязвим для CSRF, что позволило злоумышленникам изменить свою систему компании.

Новые нападения на веб-устройства были проведены в 2018 году, в том числе попытки изменить настройки DNS маршрутизаторов. Некоторые производители маршрутизаторов поспешно выпустили обновление прошивки для улучшения защиты, и посоветовали пользователь изменять настройки маршрутизатора, чтобы уменьшить риск. Подробности не были освобождены, ссылаясь на «очевидные соображения безопасности».

Introduction

Laravel makes it easy to protect your application from cross-site request forgery (CSRF) attacks. Cross-site request forgeries are a type of malicious exploit whereby unauthorized commands are performed on behalf of an authenticated user.

Laravel automatically generates a CSRF «token» for each active user session managed by the application. This token is used to verify that the authenticated user is the one actually making the requests to the application.

Anytime you define an HTML form in your application, you should include a hidden CSRF token field in the form so that the CSRF protection middleware can validate the request. You may use the Blade directive to generate the token field:

The middleware, which is included in the middleware group, will automatically verify that the token in the request input matches the token stored in the session.

CSRF Tokens & JavaScript

When building JavaScript driven applications, it is convenient to have your JavaScript HTTP library automatically attach the CSRF token to every outgoing request. By default, the Axios HTTP library provided in the file automatically sends an header using the value of the encrypted cookie. If you are not using this library, you will need to manually configure this behavior for your application.

HTTP глаголы и CSRF

• В 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 атак предотвращены СОП и ; есть метод для отправки произвольного содержимого из простой формы HTML с использованием ENCTYPE атрибута; такой поддельный запрос можно отличить от легитимных по text/plain типу контента, но если это не исполняется на сервере, CSRF может быть выполнен
• другие методы HTTP (PUT, DELETE и т.д.) может быть выдан только с использованием XMLHttpRequest с СОП и и предотвращения CSRF; Однако эти меры не будут активны на веб — сайтах, которые явно отключить их с помощью Access-Control-Allow-Origin: * заголовка

Example

The following is an example of some server-side code that generates a form
that requires a CSRF token to post back.

var cookieParser =require('cookie-parser')var csrf =require('csurf')var bodyParser =require('body-parser')var express =require('express')var csrfProtection =csrf({ cookietrue})var parseForm =bodyParser.urlencoded({ extendedfalse})var app =express()app.use(cookieParser())app.get('/form', csrfProtection,function(req,res){res.render('send',{ csrfTokenreq.csrfToken()})})app.post('/process', parseForm, csrfProtection,function(req,res){res.send('data is being processed')})

Inside the view (depending on your template language; handlebars-style
is demonstrated here), set the value as the value of a hidden
input field named :

<formaction="/process"method="POST"><inputtype="hidden"name="_csrf"value="{{csrfToken}}">  Favorite color: <inputtype="text"name="favoriteColor"><buttontype="submit">Submit</button></form>

When accessing protected routes via ajax both the csrf token will need to be
passed in the request. Typically this is done using a request header, as adding
a request header can typically be done at a central location easily without
payload modification.

The CSRF token is obtained from the call on the server-side.
This token needs to be exposed to the client-side, typically by including it in
the initial page content. One possibility is to store it in an HTML tag,
where value can then be retrieved at the time of the request by JavaScript.

The following can be included in your view (handlebar example below), where the
value came from :

<metaname="csrf-token"content="{{csrfToken}}">

var token =document.querySelector('meta').getAttribute('content')fetch('/process',{  credentials'same-origin',  headers{'CSRF-Token' token },  method'POST',  body{    favoriteColor'blue'}})

Many SPA frameworks like Angular have CSRF support built in automatically.
Typically they will reflect the value from a specific cookie, like
(which is the case for Angular).

To take advantage of this, set the value from in the cookie
used by the SPA framework. This is only necessary to do on the route that
renders the page (where or is called in Express,
for example).

The following is an example for Express of a typical SPA response:

app.all('*',function(req,res){res.cookie('XSRF-TOKEN',req.csrfToken())res.render('index')})

Note CSRF checks should only be disabled for requests that you expect to
come from outside of your website. Do not disable CSRF checks for requests
that you expect to only come from your website. An existing session, even if
it belongs to an authenticated user, is not enough to protect against CSRF
attacks.

The following is an example of how to order your routes so that certain endpoints
do not check for a valid CSRF token.

var cookieParser =require('cookie-parser')var csrf =require('csurf')var bodyParser =require('body-parser')var express =require('express')var app =express()var api =createApiRouter()app.use('/api', api)app.use(bodyParser.urlencoded({ extendedfalse}))app.use(cookieParser())app.use(csrf({ cookietrue}))app.get('/form',function(req,res){res.render('send',{ csrfTokenreq.csrfToken()})})app.post('/process',function(req,res){res.send('csrf was required to get here')})functioncreateApiRouter(){var router =newexpress.Router()router.post('/getProfile',function(req,res){res.send('no csrf to get here')})return router}

When the CSRF token validation fails, an error is thrown that has
. This can be used to display custom
error messages.

var bodyParser =require('body-parser')var cookieParser =require('cookie-parser')var csrf =require('csurf')var express =require('express')var app =express()app.use(bodyParser.urlencoded({ extendedfalse}))app.use(cookieParser())app.use(csrf({ cookietrue}))app.use(function(err,req,res,next){if(err.code!=='EBADCSRFTOKEN')returnnext(err)res.status(403)res.send('form tampered with')})

Отключение Shopify от Twitter

Сложность: Низкая
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

Shopify предоставляет интеграцию с Twitter, что позволяет владельцам магазинов постить твиты о своих продуктах. Подобным образом сервис позволяет и отключить аккаунт Twitter от связанного магазина.

URL для отключения аккаунта Twitter от магазина указан выше. При совершении запроса Shopify не валидировал CSRFтокен, что позволило злоумышленнику создать фальшивую ссылку, клик на которую приведет ничего не подозревающего владельца магазина к отключению его магазина от Twitter.

Описывая уязвимость, WeSecureApp предоставил следующий пример уязвимого запроса обратите внимание, что использование тега img делает вызов к уязвимому URL:

1 GET /auth/twitter/disconnect HTTP/1.1
2 Host: twitter-commerce.shopifyapps.com
3 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv:43.0) Gecko/20100101 Firefox/43.0
5 Accept: text/html, application/xhtml+xml, application/x 6 ml
7 Accept-Language: en-US,en;q=0.5
8 Accept-Encoding: gzip, deflate
9 Referer: https://twitter-commerce.shopifyapps.com/accou
10 nt
11 Cookie: _twitter-commerce_session=REDACTED
12 >Connection: keep-alive

Поскольку браузер выполняет GET-запрос для получения изображения по переданному URL и CSRF-токен не валидируется, пользовательский магазин теперь отключен:

1
2

Выводы

В этой ситуации, описанная уязвимость могла быть найдена при использовании проксисервера, такого, как Burp или Firefox Tamper Data, достаточно было взглянуть на запрос, отправляемый к Shopify и увидеть, что этот запрос был осуществлен с помощью GET-запроса. Поскольку это было разрушительное действие и GETзапросы не должны изменять данные на сервер, это стоит исследовать.

От чего надо защищаться?

Потенциально веб-приложение находится под угрозой множества атак. В статье я не буду затрагивать угрозы, направленные только на бэкенд (SQL-инъекции, брутфорс, DDoS и прочие). Рассмотрим атаки, направленные на уязвимости в архитектуре фронтенда, которые реализуются через действия введённого в заблуждение пользователя в браузере. Особенно стоит выделить два больших класса атак: XSS и CSRF (XSRF), породивших за пару десятилетий множество подвидов.

Конечно, список атак намного шире и постоянно пополняется. Хорошее описание для них есть на сайте проекта обеспечения безопасности веб-приложений OWASP.

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

CORS

Одностраничное приложение для взаимодействия с сервером использует XHR-запросы. Браузер накладывает на такие запросы особые политики. Если HTML-документ фронтенда и публичный интерфейс бэкенда доступны по одному хосту (протокол, домен, порт), то браузер рассматривает запрос в рамках принципа одного источника Same Origin Policy. Это означает, что он не будет препятствовать такому общению.

В принципе, проектируя приложение, можно работать в рамках этой концепции: настроить Nginx как входной веб-сервер, проксирующий запросы к одному домену по URI. В этом случае для браузера клиент и сервер будут находиться на одном домене, хотя фактически могут быть расположены на разных серверах.

Однако не всегда такой путь подойдёт. Бывает необходимость, чтобы фронтенд и API были на разных доменах, например, когда у вас несколько фронтенд-приложений на разных доменах, которые обращаются к одному API, либо политика доменных имён компании диктует свои условия. XHR-запрос с домена источника на сервер с другим доменом браузер пользователя рассматривает в рамках политики Cross-Origin Resource Sharing, или просто CORS. На такое общение браузер накладывает ряд строгих правил, основная цель которых — не дать злоумышленнику отправлять запросы с неразрешенных источников

Разработчику важно понимать, что обычный пользователь в обычной ситуации не должен столкнуться с ограничениями CORS. Ограничения начинают работать, когда механизм взаимодействия «клиент-сервер» настроен неправильно, либо когда пользователь — это злоумышленник, и пытается совершить злодейские деяния

Например, он может отправлять XHR-запросы со своего сайта, используя cookie пользователя (CSRF-атака).

Для большинства запросов настройка, разрешающая CORS, требуется только со стороны веб-сервера. Рассмотрим на примере Nginx:

Заголовок Access-Control-Allow-Origin сообщает браузеру, какие источники могут взаимодействовать с сервером. Работает это так: браузер посылает предварительный запрос OPTIONS с источника, проверяет, соответствует ли источник заголовку Access-Control-Allow-Origin и только потом отсылает основной запрос. Заголовок может принимать значение ‘*’, что значит «любой». В этом случае браузер пропустит любой кроссдоменный XHR-запрос к этому серверу. Делать это допускается в случае, когда вы проектируете публичное API, оперирующее обезличенными и не конфиденциальными данными. Например, справочник геоданных или сервис статистики посещений. На практике, такие случаи крайне редкие, в большинстве ситуаций Access-Control-Allow-Origin должен иметь значение конкретного источника.

Ещё раз отметим, что CORS-политики — это зона ответственности исключительно браузера. Если API открыто в мир, то допускается его использование с приложений, не являющимися веб-браузером. Например, с бэкенд приложений других серверов: для них заголовок Access-Control-Allow-Origin не будет значить ровным счетом ничего, поэтому за доступность API можно не беспокоиться.

Only accepting POST requests

Applications can be developed to only accept POST requests for the
execution of business logic. The misconception is that since the
attacker cannot construct a malicious link, a CSRF attack cannot be
executed. Unfortunately, this logic is incorrect. There are numerous
methods in which an attacker can trick a victim into submitting a forged
POST request, such as a simple form hosted in an attacker’s Website with
hidden values. This form can be triggered automatically by JavaScript or
can be triggered by the victim who thinks the form will do something
else.

A number of flawed ideas for defending against CSRF attacks have been
developed over time. Here are a few that we recommend you avoid.

Методы защиты

Первое, что приходит на ум, когда речь заходит о защите от CSRF – это проверка значения заголовка Referer. И действительно, поскольку подделка HTTP-запросов заключается в передаче запроса с третьего сайта, контроль исходной страницы, чей адрес автоматически добавляется браузером в заголовки запроса, может решить проблему.
Однако этот механизм имеет ряд недостатков. Во-первых – перед разработчиком встает вопрос об обработке запросов, не имеющих заголовка Referer как такового. Многие из персональных межсетевых экранов и анонимизирующих proxy-серверов вырезают Referer, как потенциально небезопасный заголовок. Соответственно, если сервер будет игнорировать подобные запросы, группа наиболее «параноидально» настроенных граждан не смогут с ним работать.
Во-вторых, в некоторых ситуациях заголовок Referer может быть подделан, например, с помощью уже упоминавшегося трюка с Flash. Если пользователь применяет IE 6.0, то содержимое заголовка запроса может быть модифицировано c использованием ошибки в реализации XmlHttxmpquest. Уязвимость заключается в возможности использования символов перевода строки в имени HTTP-метода, что позволяет изменять заголовки и даже внедрять дополнительный запрос. Эта уязвимость была обнаружена Amit Clein () в 2005 году и снова открыта в 2007. Ограничением этого метода является то, что он работает только в случае наличия между пользователем и сервером HTTP-Proxy или размещения серверов на одном IP-адресе, но с разными доменными именами.
Другой распространенный метод – добавление уникального параметра к каждому запросу, который затем проверяется сервером. Параметр может добавляться к URL при использовании GET запроса как например, в Google Desktop или в виде спрятанного параметра формы, при использовании POST. Значение параметра может быть произвольным, главное, чтобы злоумышленник не мог его предсказать, например – значение сессии пользователя.

Рис. 6. Защита от CSRF в Bitrix

Для быстрого добавления функции проверки CSRF в свое приложение можно воспользоваться следующим подходом:
1. Добавлять в каждую генерируемую страницу небольшой JavaScript, дописывающий во все формы дополнительный скрытый параметр, которому присваивается значение Cookie.
2. Проверять на сервере, что переданные клиентом с помощью метода POST данные содержат значение, равное текущему значению Cookie.
Пример подобного клиентского сценария приведен ниже:

Дальнейшим развитием этого подхода является сохранение идентификатора сессии не в Cookie, а в качестве скрытого параметра формы (например, VIEWSTATE).
В качестве метода противодействия CSRF могут использоваться различные варианты тестов Тьюринга, например, хорошо известные всем изображения — CAPTCHA. Другим популярным вариантом является необходимость ввода пользовательского пароля при изменении критичных настроек.

Рис. 7. Защита от CSRF в mail.ru

Таким образом, Cross-Site Request Forgery являются атакой, направленной на клиента Web-приложения и использующей недостаточную проверку источника HTTP-запроса. Для защиты от подобных атак может использоваться дополнительный контроль источника запроса на основе заголовка Referer или дополнительного «случайного» параметра.

Сергей Гордейчик работает системным архитектором компании Positive Technologies, где он специализируется в вопросах безопасности приложений, безопасности беспроводных и мобильных технологий. Автор также является ведущим разработчиком курсов «Безопасность беспроводных сетей», «Анализ и оценка защищенности Web-приложений» учебного центра «Информзащита» . Опубликовал несколько десятков статей в “Windows IT Pro/RE”, SecurityLab и других изданиях. Является участником проектов Web Application Security Consortium (WASC).

Examples

How does the attack work?

There are numerous ways in which an end user can be tricked into loading
information from or submitting information to a web application. In
order to execute an attack, we must first understand how to generate a
valid malicious request for our victim to execute. Let us consider the
following example: Alice wishes to transfer $100 to Bob using the
bank.com web application that is vulnerable to CSRF. Maria, an
attacker, wants to trick Alice into sending the money to Maria instead.
The attack will comprise the following steps:

1. building an exploit URL or script
2. tricking Alice into executing the action with social
   engineering

GET scenario

If the application was designed to primarily use GET requests to
transfer parameters and execute actions, the money transfer operation
might be reduced to a request like:

Maria now decides to exploit this web application vulnerability using
Alice as the victim. Maria first constructs the following exploit URL
which will transfer $100,000 from Alice’s account to Maria’s account. Maria
takes the original command URL and replaces the beneficiary name with
herself, raising the transfer amount significantly at the same time:

The social engineering aspect of the
attack tricks Alice into loading this URL when Alice is logged into the
bank application. This is usually done with one of the following
techniques:

• sending an unsolicited email with HTML content
• planting an exploit URL or script on pages that are likely to be
  visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the
victim to click it:

Or as a 0x0 fake image:

A real life example of CSRF attack on an application using GET was a
uTorrent
exploit
from 2008 that was used on a mass scale to download malware.

POST scenario

The only difference between GET and POST attacks is how the attack is
being executed by the victim. Let’s assume the bank now uses POST and
the vulnerable request looks like this:

Such a request cannot be delivered using standard A or IMG tags, but can
be delivered using a FORM tags:

This form will require the user to click on the submit button, but this
can be also executed automatically using JavaScript:

Other HTTP methods

Modern web application APIs frequently use other HTTP methods, such as
PUT or DELETE. Let’s assume the vulnerable bank uses PUT that takes a
JSON block as an argument:

Such requests can be executed with JavaScript embedded into an exploit
page:

Fortunately, this request will not be executed by modern web
browsers thanks to same-origin policy
restrictions. This restriction is enabled by default unless the target
web site explicitly opens up cross-origin requests from the attacker’s
(or everyone’s) origin by using

with the following header:

Защита

В примере выше атака использовала слабое звено авторизации.

Куки позволяют сайту проверить, что пришёл именно Вася, но ничего не говорят про данные, которые он отправляет.

Иначе говоря, куки не гарантируют, что форму создал именно Вася. Они только удостоверяют личность, но не данные.

Типичный способ защиты сайтов – это «секретный ключ» (), специальное значение, которое генерируется случайным образом и сохраняется в сессии посетителя. Его знает только сервер, посетителю мы его даже не будем показывать.

Затем на основе ключа генерируется «токен» (). Токен делается так, чтобы с одной стороны он был отличен от ключа, в частности, может быть много токенов для одного ключа, с другой – чтобы было легко проверить по токену, сгенерирован ли он на основе данного ключа или нет.

Для каждого токена нужно дополнительное случайное значение, которое называют «соль» .

Формула вычисления токена:

Например:

1. В сессии хранится , это значение создаётся один раз.
2. Для нового токена сгенерируем , например пусть .
3. .

Это значение – с одной стороны, случайное, с другой – имея такой , мы можем взять его первую часть в качестве и, зная , проверить по формуле, верно ли он вычислен.

Не зная , невозможно сгенерировать token, который сервер воспримет как правильный.

Далее, токен добавляется в качестве скрытого поля к каждой форме, генерируемой на сервере.

То есть, «честная» форма для отсылки сообщений, созданная на , будет выглядеть так:

При её отправке сервер проверит поле , удостоверится в правильности токена, и лишь после этого отошлёт сообщение.

«Злая страница» при всём желании не сможет сгенерировать подобную форму, так как не владеет , и токен будет неверным.

Такой токен также называют «подписью» формы, которая удостоверяет, что форма сгенерирована именно на сервере.

Подпись с полями формы

Эта подпись говорит о том, что автор формы – сервер, но ничего не гарантирует относительно её содержания.

Есть ситуации, когда мы хотим быть уверены, что некоторые из полей формы посетитель не изменил самовольно. Тогда мы можем включить в MD5 для формулы токена эти поля, например:

При отправке формы сервер проверит подпись, подставив в неё известный ему и присланное значение . При несовпадении либо не тот (хакер), либо изменено.

Подделка межсайтовых запросов (CSRF) простыми словами

• Предположим, вы в настоящее время вошли в систему онлайн-банкинга по адресу
• Предположим, перевод денег из приведет к запросу (концептуально) формы , (Ваш номер счета не нужен, поскольку он подразумевается вашим логином.)
• Ты посещаешь , не зная, что это вредоносный сайт.
• Если владелец этого сайта знает форму вышеуказанного запроса (просто!) И правильно догадывается, что вы вошли в систему (требуется немного удачи!), они могли бы включить на своей странице запрос, как (где это номер их счета Каймановых островов и это сумма, которую вы раньше считали Рады обладать).
• Вы извлек это страница, так ваш браузер сделает этот запрос.
• Ваш банк не может распознать источник этого запроса: ваш веб-браузер отправит запрос вместе с вашим печенье, и это будет выглядеть совершенно законно. Там идут ваши деньги!

Это мир без токенов CSRF.

Теперь к лучшему с Токены CSRF:

• Запрос на передачу расширен третьим аргументом: ,
• Этот токен — огромное случайное число, которое невозможно угадать. будет размещать на своей веб-странице, когда они будут служить вам. это разные каждый раз, когда они подают любую страницу кому-либо.
• Злоумышленник не может угадать токен, не может убедить ваш веб-браузер отказаться от него (если браузер работает правильно …), и поэтому злоумышленник не быть в состоянии создать действительный запрос, потому что запросы с неправильным токеном (или без токена) будут отклонены ,

Результат: Вы держите свой денежные единицы. Я предлагаю вам пожертвовать часть этого в Википедии.

(Ваш пробег может отличаться.)

РЕДАКТИРОВАТЬ из комментария стоит прочитать:

Стоит отметить, что сценарий из обычно не имеет доступа к вашему токену анти-CSRF от из-за контроля доступа HTTP. Эта заметка важна для некоторых людей, которые необоснованно отправляют заголовок за каждый ответ сайта, не зная, для чего он нужен, просто потому, что они не могут использовать API с другого сайта.

Common CSRF vulnerabilities

Most interesting CSRF vulnerabilities arise due to mistakes made in the validation of CSRF tokens.

In the previous example, suppose that the application now includes a CSRF token within the request to change the user’s password:

This ought to prevent CSRF attacks because it violates the necessary conditions for a CSRF vulnerability: the application no longer relies solely on cookies for session handling, and the request contains a parameter whose value an attacker cannot determine. However, there are various ways in which the defense can be broken, meaning that the application is still vulnerable to CSRF.

Validation of CSRF token depends on request method

Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.

In this situation, the attacker can switch to the GET method to bypass the validation and deliver a CSRF attack:

LAB
CSRF where token validation depends on request method

Validation of CSRF token depends on token being present

Some applications correctly validate the token when it is present but skip the validation if the token is omitted.

In this situation, the attacker can remove the entire parameter containing the token (not just its value) to bypass the validation and deliver a CSRF attack:

LAB
CSRF where token validation depends on token being present

CSRF token is not tied to the user session

Some applications do not validate that the token belongs to the same session as the user who is making the request. Instead, the application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool.

In this situation, the attacker can log in to the application using their own account, obtain a valid token, and then feed that token to the victim user in their CSRF attack.

LAB
CSRF where token is not tied to user session

CSRF token is tied to a non-session cookie

In a variation on the preceding vulnerability, some applications do tie the CSRF token to a cookie, but not to the same cookie that is used to track sessions. This can easily occur when an application employs two different frameworks, one for session handling and one for CSRF protection, which are not integrated together:

This situation is harder to exploit but is still vulnerable. If the web site contains any behavior that allows an attacker to set a cookie in a victim’s browser, then an attack is possible. The attacker can log in to the application using their own account, obtain a valid token and associated cookie, leverage the cookie-setting behavior to place their cookie into the victim’s browser, and feed their token to the victim in their CSRF attack.

LAB
CSRF where token is tied to non-session cookie

Note

The cookie-setting behavior does not even need to exist within the same web application as the CSRF vulnerability. Any other application within the same overall DNS domain can potentially be leveraged to set cookies in the application that is being targeted, if the cookie that is controlled has suitable scope. For example, a cookie-setting function on could be leveraged to place a cookie that is submitted to .

CSRF token is simply duplicated in a cookie

In a further variation on the preceding vulnerability, some applications do not maintain any server-side record of tokens that have been issued, but instead duplicate each token within a cookie and a request parameter. When the subsequent request is validated, the application simply verifies that the token submitted in the request parameter matches the value submitted in the cookie. This is sometimes called the «double submit» defense against CSRF, and is advocated because it is simple to implement and avoids the need for any server-side state:

In this situation, the attacker can again perform a CSRF attack if the web site contains any cookie setting functionality. Here, the attacker doesn’t need to obtain a valid token of their own. They simply invent a token (perhaps in the required format, if that is being checked), leverage the cookie-setting behavior to place their cookie into the victim’s browser, and feed their token to the victim in their CSRF attack.

LAB
CSRF where token is duplicated in cookie