CSRF-токен
В этой статье рассмотрим, что такое Сross-Site Request Forgery и как включить в Spring Boot приложение CSRF-токен — защиту от этого мошенничества. Назвать этот токен можно было бы «анти-CSRF-токен».
Same Origin Policy и CSRF (cross-site request forgery)
Обычно запросы, сделанные в браузере с одного домена на другой, не проходят, поскольку браузер придерживается Same Origin Policy. Это политика безопасности, защищающая одни сайты от других.
Например, пусть пользователь случайно заходит на домен evil.com (мошеннический сайт) и щелкает там яркую кнопку, которая выполняет либо PUT-запрос, либо DELETE-запрос на bank.com. И так случайно получилось, что этот пользователь зарегистрирован на bank.com и в браузере хранятся куки к нему. Благодаря политике безопасности браузера, ничего плохого не случится. Потому что браузер сначала вышлет так называемый «preflight», то есть предварительный OPTIONS-запрос на bank.com с заголовком
и затем отправит за ним настоящий PUT/DELETE-запрос, но только в том случае, если в ответе пришло разрешение на отправку запросов от evil.com. В противном случае в метод PUT/DELETE банковского сайта мы даже не попадем.
Но есть запросы, которые отправляются сразу, без предварительного запроса, так называемые simple requests. Это GET, HEAD, POST с определенным Content-Type. В частности, POST-запросы с формы. Такой запрос сразу идет в контроллер. А учитывая, что куки браузер отправляет автоматически, запрос попадет в защищенный контроллер и выполнит действие на банковском сайте. Хотя ответ получить и распарсить нельзя, действие будет выполнено.
Ниже рассмотрим, как это происходит. В примере одно приложение на одном домене делает POST-запрос на другой домен, где работает второе приложение. Рассмотрим, как защититься от таких запросов с помощью CSRF-токена.
Пример жульничества
Создадим два приложения на Spring Boot:
Поскольку в примере мы будем делать запрос на «другой домен», пропишем для localhost:8080 новое имя в файле hosts:
А именно, добавим в файл hosts строку:
Теперь к приложению-мишени будем обращаться по адресу http://bank-server:8080/..вместо http://localhost:8080..
Приложение-мишень
Итак, пусть в нашем приложении есть контроллер и форма, с которой что-то добавляется:
Добавление
Форма на Thymeleaf выглядит так:
При этом адрес http://bank-server:8080/add защищен, доступ к нему возможен только благодаря куки JSESSIONID после входа с помощью формы логина.
В приложении задан единственный in-memory пользователь с именем user и паролем user:
Выше прописано, что все запросы доступны только аутентифицированным пользователям (в том числе наша форма — ее получение по адресу /add методом GET и отправка методом POST). Форма находится в шаблоне add.html
Проверку CSRF-токена мы отключили выше отдельной строкой:
Это сделано для того, чтобы продемонстрировать атаку с помощью второго приложения ниже. А затем включить CSRF-токен обратно. (По умолчанию он и так включен, просто нужно не забывать добавлять его и на форму, что будет в показано самом конце).
Мошенническое приложение
Второе приложение совсем простое, оно состоит из одного view с кнопкой атаки POST (полный код тут):
Сайт жуликов
Кнопка отправляет форму со скрытыми полями: и text=«document». Если в браузере мы залогинены в приложении http://bank-server:8080 и откроем мошеннический сайт localhost:8081 с вышеприведенной кнопкой и щелкнем ее, то сохраненный куки JSESSIONID отправляется тоже, и мы попадаем в защищенный метод add() контроллера DocumentController банковского сайта. Документ добавляется.
Защита с помощью CSRF-токена
Чтобы защититься от таких запросов, нужно включить CSRF-токен, то есть убрать строку отключения, которую мы добавили выше:
Теперь когда пользователь логинится на сайт http://bank-server:8080, ему выделяется специальный CSRF-токен. Он хранится в сессии и должен отправляться как скрытое поле со всех форм (также он должен прилагаться в XMLHttpRequest-запросах PUT, DELETE, POST — это для JavaScript). Выше мы показали только одну атаку, но при определенных настройках Spring MVC в определенных браузерах возможны и более сложные атаки. И хотя браузеры становятся все более безопасными, как и сам Spring MVC, все равно Spring Security имеет вот такое требование и для PUT, и для DELETE-запросов, хотя для них существуют «preflight» запросы от браузера. Но эти настройки CSRF-токена можно и поменять — убрать некоторые методы или некоторые url — сделать так, чтобы для них не требовался токен.
Итак, токен в POST-запросах сейчас требуется. Если оставить все как есть, то наше собственное банковское приложение не заработает — при попытке отправить форму получим 403. Надо сделать так, чтобы выданный CSRF-токен отправлялся. Для этого добавим его как скрытое поле на форму в наш Thymeleaf-шаблон:
Все, теперь и наше приложение работает, и с чужого сайта форму отправить нельзя, потому что мошенники не знают CSRF-токен. В отличие от JSESSIONID, он не хранится в куки браузера и не отправляется автоматически при запросах на банковский сайт.
Итоги
Исходный код обоих приложений есть на GitHub.
Основные характеристики Spring Security 3.2.0 RC1: защита CSRF
Этот пост был написан Робом Винчем в блоге SpringSource.
В этой первой записи я расскажу о поддержке CSRF в Spring Security. В следующем посте я рассмотрю различные заголовки безопасности, которые были добавлены.
CSRF ATTACKS
Предположим, что веб-сайт вашего банка предоставляет форму, которая позволяет переводить деньги от текущего пользователя на другой банковский счет. Например, HTTP-запрос может выглядеть так:
Теперь представьте, что вы проходите проверку подлинности на веб-сайте вашего банка, а затем, не выходя из системы, посетите злой веб-сайт. Злой сайт содержит HTML-страницу со следующей формой:
Вам нравится выигрывать деньги, поэтому вы нажимаете на кнопку отправки. При этом вы непреднамеренно перевели 100 долларов злоумышленнику. Это происходит потому, что, хотя злой сайт не может видеть ваши куки, куки, связанные с вашим банком, по-прежнему отправляются вместе с запросом.
Хуже всего то, что весь этот процесс мог быть автоматизирован с использованием JavaScript. Это означает, что вам даже не нужно нажимать на кнопку. Так как же мы защищаемся от таких атак?
СИНХРОНИЗАТОР ЗНАКОМ
Проблема в том, что HTTP-запрос с веб-сайта банка и запрос с злого веб-сайта в точности совпадают. Это означает, что нет способа отклонить запросы, поступающие со злого веб-сайта, и разрешить запросы, поступающие с веб-сайта банка. Для защиты от CSRF-атак нам нужно убедиться, что в запросе есть что-то, что злой сайт не может предоставить.
Давайте посмотрим, как изменится наш пример. Предположим, что случайно сгенерированный токен присутствует в параметре HTTP с именем _csrf. Например, запрос на перевод денег будет выглядеть так:
Вы заметите, что мы добавили параметр _csrf со случайным значением. Теперь злой сайт не сможет угадать правильное значение параметра _csrf (который должен быть явно указан на злом сайте), и передача не удастся, когда сервер сравнит реальный токен с ожидаемым токеном.
ИСПОЛЬЗОВАНИЕ ПОДДЕРЖКИ CSRF SPRING SECURITY
Итак, какие шаги необходимы для использования Spring Security для защиты нашего сайта от CSRF-атак? Шаги для использования защиты CSRF Spring Security описаны ниже:
Используйте правильные HTTP-глаголы
Первый шаг к защите от CSRF-атак — убедиться, что ваш сайт использует правильные HTTP-глаголы. В частности, прежде чем поддержка CSRF в Spring Security станет полезной, вы должны быть уверены, что ваше приложение использует PATCH, POST, PUT и / или DELETE для всего, что изменяет состояние. Это не ограничение поддержки Spring Security, а общее требование правильного предотвращения CSRF.
Csrf spring security что это
Before we discuss how Spring Security can protect applications from CSRF attacks, we will explain what a CSRF attack is. Let’s take a look at a concrete example to get a better understanding.
Assume that your bank’s website provides a form that allows transferring money from the currently logged in user to another bank account. For example, the HTTP request might look like:
Now pretend you authenticate to your bank’s website and then, without logging out, visit an evil website. The evil website contains an HTML page with the following form:
Worst yet, this whole process could have been automated using JavaScript. This means you didn’t even need to click on the button. So how do we protect ourselves from such attacks?
18.2 Synchronizer Token Pattern
The issue is that the HTTP request from the bank’s website and the request from the evil website are exactly the same. This means there is no way to reject requests coming from the evil website and allow requests coming from the bank’s website. To protect against CSRF attacks we need to ensure there is something in the request that the evil site is unable to provide.
One solution is to use the Synchronizer Token Pattern. This solution is to ensure that each request requires, in addition to our session cookie, a randomly generated token as an HTTP parameter. When a request is submitted, the server must look up the expected value for the parameter and compare it against the actual value in the request. If the values do not match, the request should fail.
We can relax the expectations to only require the token for each HTTP request that updates state. This can be safely done since the same origin policy ensures the evil site cannot read the response. Additionally, we do not want to include the random token in HTTP GET as this can cause the tokens to be leaked.
Let’s take a look at how our example would change. Assume the randomly generated token is present in an HTTP parameter named _csrf. For example, the request to transfer money would look like this:
You will notice that we added the _csrf parameter with a random value. Now the evil website will not be able to guess the correct value for the _csrf parameter (which must be explicitly provided on the evil website) and the transfer will fail when the server compares the actual token to the expected token.
18.3 When to use CSRF protection
When should you use CSRF protection? Our recommendation is to use CSRF protection for any request that could be processed by a browser by normal users. If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.
18.3.1 CSRF protection and JSON
A common question is «do I need to protect JSON requests made by javascript?» The short answer is, it depends. However, you must be very careful as there are CSRF exploits that can impact JSON requests. For example, a malicious user can create a CSRF with JSON using the following form:
This will produce the following JSON structure
If an application were not validating the Content-Type, then it would be exposed to this exploit. Depending on the setup, a Spring MVC application that validates the Content-Type could still be exploited by updating the URL suffix to end with «.json» as shown below:
18.3.2 CSRF and Stateless Browser Applications
What if my application is stateless? That doesn’t necessarily mean you are protected. In fact, if a user does not need to perform any actions in the web browser for a given request, they are likely still vulnerable to CSRF attacks.
For example, consider an application uses a custom cookie that contains all the state within it for authentication instead of the JSESSIONID. When the CSRF attack is made the custom cookie will be sent with the request in the same manner that the JSESSIONID cookie was sent in our previous example.
Users using basic authentication are also vulnerable to CSRF attacks since the browser will automatically include the username password in any requests in the same manner that the JSESSIONID cookie was sent in our previous example.
18.4 Using Spring Security CSRF Protection
So what are the steps necessary to use Spring Security’s to protect our site against CSRF attacks? The steps to using Spring Security’s CSRF protection are outlined below:
18.4.1 Use proper HTTP verbs
The first step to protecting against CSRF attacks is to ensure your website uses proper HTTP verbs. Specifically, before Spring Security’s CSRF support can be of use, you need to be certain that your application is using PATCH, POST, PUT, and/or DELETE for anything that modifies state.
This is not a limitation of Spring Security’s support, but instead a general requirement for proper CSRF prevention. The reason is that including private information in an HTTP GET can cause the information to be leaked. See RFC 2616 Section 15.1.3 Encoding Sensitive Information in URI’s for general guidance on using POST instead of GET for sensitive information.
18.4.2 Configure CSRF Protection
The next step is to include Spring Security’s CSRF protection within your application. Some frameworks handle invalid CSRF tokens by invaliding the user’s session, but this causes its own problems. Instead by default Spring Security’s CSRF protection will produce an HTTP 403 access denied. This can be customized by configuring the AccessDeniedHandler to process InvalidCsrfTokenException differently.
As of Spring Security 4.0, CSRF protection is enabled by default with XML configuration. If you would like to disable CSRF protection, the corresponding XML configuration can be seen below.
CSRF protection is enabled by default with Java Configuration. If you would like to disable CSRF, the corresponding Java configuration can be seen below. Refer to the Javadoc of csrf() for additional customizations in how CSRF protection is configured.
Руководство по защите CSRF в Spring Security
Узнайте, как CSRF-атаки работают в практическом приложении Spring, а затем как включить защиту от таких атак с помощью Spring Security.
1. Обзор
В этом уроке мы обсудим атаки CSRF на подделку межсайтовых запросов и способы их предотвращения с помощью Spring Security.
Дальнейшее чтение:
Защита CSRF с пружинным MVC и Thymeleaf
Автоматическая настройка безопасности весенней загрузки
Введение в безопасность метода Spring
2. Две простые атаки CSRF
Существует несколько форм CSRF – атак-давайте обсудим некоторые из наиболее распространенных из них.
2.1. ПРИВЕДИТЕ примеры
Рассмотрим следующий GET запрос, используемый зарегистрированным пользователем для перевода денег на определенный банковский счет “1234” :
Если злоумышленник хочет вместо этого перевести деньги со счета жертвы на свой собственный счет – “5678” – он должен заставить жертву инициировать запрос:
Есть несколько способов сделать это:
2.2. Пример публикации
Если основной запрос должен быть запросом POST – например:
Затем злоумышленник должен заставить жертву выполнить аналогичное:
Однако форма может быть отправлена автоматически с помощью Javascript – следующим образом:
2.3. Практическое Моделирование
Теперь, когда мы понимаем, как выглядит атака CSRF, давайте смоделируем эти примеры в приложении Spring.
Мы начнем с простой реализации контроллера – Банковского контроллера :
И давайте также создадим базовую HTML-страницу, которая запускает операцию банковского перевода:
Это страница основного приложения, запущенного в исходном домене.
Теперь – давайте посмотрим, как будет выглядеть страница злоумышленника :
Эта страница будет работать в другом домене – домене злоумышленника.
Наконец, давайте запустим два приложения – исходное и атакующее – локально и сначала получим доступ к исходной странице:
Затем давайте перейдем на страницу злоумышленника:
Отслеживая точные запросы, исходящие с этой страницы злоумышленника, мы сможем сразу же определить проблемный запрос, попав в исходное приложение и полностью аутентифицировавшись.
3. Конфигурация безопасности Пружины
3.1. Конфигурация Java
Защита CSRF включена по умолчанию в конфигурации Java. Мы все еще можем отключить его, если понадобится:
3.2. Конфигурация XML
В более старой конфигурации XML (pre Spring Security 4) защита CSRF была отключена по умолчанию, и мы могли бы включить ее следующим образом:
Начиная с Spring Security 4.x – защита CSRF также включена по умолчанию в конфигурации XML; мы, конечно, все еще можем отключить ее, если нам нужно:
3.3. Дополнительные параметры формы
Наконец, с включенной защитой CSRF на стороне сервера нам также нужно будет включить маркер CSRF в наши запросы на стороне клиента:
3.4. Использование JSON
Мы не можем отправить токен CSRF в качестве параметра, если мы используем JSON; вместо этого мы можем отправить токен в заголовке.
Сначала нам нужно будет включить токен на нашу страницу – и для этого мы можем использовать мета-теги:
Затем мы построим заголовок:
4. Тест CSRF отключен
Со всем этим мы перейдем к некоторым тестам.
Давайте сначала попробуем отправить простой запрос POST, когда CSRF отключен:
Как вы, возможно, заметили, мы используем базовый класс для хранения общей вспомогательной логики тестирования – CsrfAbstractIntegrationTest :
Обратите внимание, что, когда у пользователя были правильные учетные данные безопасности, запрос был успешно выполнен – никакой дополнительной информации не требовалось.
Это означает, что злоумышленник может просто использовать любой из ранее рассмотренных векторов атаки, чтобы легко скомпрометировать систему.
5. Тест с поддержкой CSRF
Теперь давайте включим защиту CSRF и посмотрим, в чем разница:
Теперь, как этот тест использует другую конфигурацию безопасности – ту, в которой включена защита CSRF.
Теперь запрос POST просто завершится неудачей, если токен CSRF не будет включен, что, конечно, означает, что более ранние атаки больше не являются вариантом.
6. Заключение
В этой статье мы обсудили несколько атак CSRF и способы их предотвращения с помощью Spring Security.
полную реализацию этого учебника можно найти в проекте GitHub – это проект на основе Maven, поэтому его должно быть легко импортировать и запускать как есть.
Защита от CSRF в Spring MVC, Thymeleaf, приложении Spring Security
Подделка межсайтовых запросов (CSRF) — это атака, которая заставляет конечного пользователя выполнять нежелательные действия в веб-приложении, в котором он / она в настоящее время проходит проверку подлинности. Предотвращение CSRF-атак в приложении Spring MVC / Thymeleaf довольно легко, если вы используете Spring Security 3.2 и выше.
Как проверить?
Для тестирования я создал приложение с ограниченной областью, куда я могу отправить форму. Исходный код формы:
Зная, что URL действия был http: // localhost: 8080 / message, я создал отдельную страницу с HTTP-запросом, ссылающимся на этот URL (со всеми параметрами):
Как обезопасить?
Если вы используете конфигурацию XML с Spring Security, защита CSRF должна быть включена:
В случае конфигурации Java — она включена по умолчанию.
Начиная с версии Thymeleaf 2.1, токен CSRF будет автоматически добавляться в формы со скрытым вводом:
Однако следует помнить, что включение защиты CSRF гарантирует, что для выхода требуется маркер CSRF. Я использовал JavaScript для отправки скрытой формы:
Резюме
В этой короткой статье я показал, как легко вы можете использовать защиту CSRF при работе с Spring MVC (3.1+), Thymeleaf (2.1+) и Spring Security (3.2+). Начиная с Spring Security 4 CSRF будет включен по умолчанию также при использовании конфигурации XML. Обратите внимание, что HTTP-сессия используется для хранения токена CSRF. Но это можно легко изменить. Для более подробной информации смотрите ссылки.
