Руководство по защите CSRF в Spring Security

16 мая 2022 г. · 8 мин. чтения

1. Обзор

В этом руководстве мы обсудим атаки подделки межсайтовых запросов (CSRF) и способы их предотвращения с помощью Spring Security.

2. Две простые CSRF-атаки

Существует несколько форм CSRF-атак. Давайте обсудим некоторые из наиболее распространенных.

2.1. ПОЛУЧИТЬ примеры

Давайте рассмотрим следующий запрос GET , используемый вошедшим в систему пользователем для перевода денег на определенный банковский счет 1234 :

GET http://bank.com/transfer?accountNo=1234&amount=100

Если злоумышленник вместо этого хочет перевести деньги со счета жертвы на свой собственный счет — 5678 — ему нужно заставить жертву инициировать запрос:

GET http://bank.com/transfer?accountNo=5678&amount=1000

Есть несколько способов сделать это:

Ссылка — Злоумышленник может убедить жертву перейти по этой ссылке, например, для выполнения перевода:

<a href="http://bank.com/transfer?accountNo=5678&amount=1000">
Show Kittens Pictures
</a>

Изображение — злоумышленник может использовать тег <img/> с целевым URL-адресом в качестве источника изображения. Другими словами, щелчок даже не нужен. Запрос будет автоматически выполнен при загрузке страницы:

<img src="http://bank.com/transfer?accountNo=5678&amount=1000"/>

2.2. Пример POST

Предположим, что основной запрос должен быть POST-запросом:

POST http://bank.com/transfer
accountNo=1234&amount=100

В этом случае злоумышленнику необходимо, чтобы жертва выполнила аналогичный запрос:

POST http://bank.com/transfer
accountNo=5678&amount=1000

В этом случае не будут работать ни теги <a> , ни <img/> .

Злоумышленнику понадобится <form> :

<form action="http://bank.com/transfer" method="POST">
    <input type="hidden" name="accountNo" value="5678"/>
    <input type="hidden" name="amount" value="1000"/>
    <input type="submit" value="Show Kittens Pictures"/>
</form>

Однако форма может быть отправлена автоматически с помощью JavaScript:

<body onload="document.forms[0].submit()">
<form>
...

2.3. Практическое моделирование

Теперь, когда мы понимаем, как выглядит атака CSRF, давайте смоделируем эти примеры в приложении Spring.

Мы собираемся начать с реализации простого контроллера — BankController :

@Controller
public class BankController {
    private Logger logger = LoggerFactory.getLogger(getClass());

    @RequestMapping(value = "/transfer", method = RequestMethod.GET)
    @ResponseBody
    public String transfer(@RequestParam("accountNo") int accountNo, 
      @RequestParam("amount") final int amount) {
        logger.info("Transfer to {}", accountNo);
        ...
    }

    @RequestMapping(value = "/transfer", method = RequestMethod.POST)
    @ResponseStatus(HttpStatus.OK)
    public void transfer2(@RequestParam("accountNo") int accountNo, 
      @RequestParam("amount") final int amount) {
        logger.info("Transfer to {}", accountNo);
        ...
    }
}

И давайте также иметь базовую HTML-страницу, которая запускает операцию банковского перевода:

<html>
<body>
    <h1>CSRF test on Origin</h1>
    <a href="transfer?accountNo=1234&amount=100">Transfer Money to John</a>
    
    <form action="transfer" method="POST">
        <label>Account Number</label> 
        <input name="accountNo" type="number"/>

        <label>Amount</label>         
        <input name="amount" type="number"/>

        <input type="submit">
    </form>
</body>
</html>

Это страница основного приложения, работающего на исходном домене.

Следует отметить, что мы реализовали GET через простую ссылку и POST через простую <form> .

Теперь давайте посмотрим, как будет выглядеть страница злоумышленника:

<html>
<body>
    <a href="http://localhost:8080/transfer?accountNo=5678&amount=1000">Show Kittens Pictures</a>
    
    <img src="http://localhost:8080/transfer?accountNo=5678&amount=1000"/>
    
    <form action="http://localhost:8080/transfer" method="POST">
        <input name="accountNo" type="hidden" value="5678"/>
        <input name="amount" type="hidden" value="1000"/>
        <input type="submit" value="Show Kittens Picture">
    </form>
</body>
</html>

Эта страница будет работать на другом домене — домене злоумышленника.

Наконец, давайте запустим исходное приложение и приложение злоумышленника локально.

Чтобы атака сработала, пользователь должен пройти аутентификацию в исходном приложении с помощью файла cookie сеанса.

Давайте сначала получим доступ к исходной странице приложения:

http://localhost:8081/spring-rest-full/csrfHome.html

Он установит файл cookie JSESSIONID в нашем браузере.

Затем давайте получим доступ к странице злоумышленника:

http://localhost:8081/spring-security-rest/api/csrfAttacker.html

Если мы отследим запросы, исходящие с этой страницы злоумышленника, мы сможем определить те, которые попали в исходное приложение. Поскольку файл cookie JSESSIONID автоматически отправляется с этими запросами, Spring аутентифицирует их, как если бы они исходили из исходного домена.

3. Приложение Spring MVC

Для защиты приложений MVC Spring добавляет токен CSRF к каждому сгенерированному представлению. Этот токен должен отправляться на сервер при каждом HTTP-запросе, который изменяет состояние (PATCH, POST, PUT и DELETE, а `` не GET). Это защищает наше приложение от CSRF-атак, поскольку злоумышленник не может получить этот токен со своей собственной страницы.

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

3.1. Конфигурация безопасности Spring

В более старой конфигурации XML (до Spring Security 4) защита CSRF была отключена по умолчанию, и мы могли включить ее по мере необходимости:

<http>
    ...
    <csrf />
</http>

Начиная с Spring Security 4.x защита CSRF включена по умолчанию.

Эта конфигурация по умолчанию добавляет токен CSRF к атрибуту HttpServletRequest с именем _csrf .

Если нам нужно, мы можем отключить эту конфигурацию:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
      .csrf().disable();
}

3.2. Конфигурация клиента

Теперь нам нужно включить токен CSRF в наши запросы.

Атрибут _csrf содержит следующую информацию:

token — значение токена CSRF
имя_параметра — имя параметра HTML-формы, которое должно включать значение токена.
headerName — имя HTTP-заголовка, который должен включать значение токена

Если наши представления используют HTML-формы, мы будем использовать значения параметраName и токена для добавления скрытого ввода:

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

Если наши представления используют JSON, нам нужно использовать значения headerName и token для добавления HTTP-заголовка.

Сначала нам нужно включить значение токена и имя заголовка в метатеги:

<meta name="_csrf" content="${_csrf.token}"/>
<meta name="_csrf_header" content="${_csrf.headerName}"/>

Затем давайте получим значения метатегов с помощью JQuery:

var token = $("meta[name='_csrf']").attr("content");
var header = $("meta[name='_csrf_header']").attr("content");

Наконец, давайте используем эти значения для установки нашего заголовка XHR:

$(document).ajaxSend(function(e, xhr, options) {
    xhr.setRequestHeader(header, token);
});

4. Spring API без сохранения состояния

Давайте рассмотрим случай, когда Spring API без сохранения состояния используется внешним интерфейсом.

Как объясняется в нашей специальной статье , нам нужно понять, требуется ли защита CSRF для нашего API без сохранения состояния.

Если наш API без сохранения состояния использует аутентификацию на основе токенов, такую как JWT, нам не нужна защита CSRF, и мы должны отключить ее, как мы видели ранее.

Однако, если наш API без сохранения состояния использует аутентификацию cookie сеанса, нам необходимо включить защиту CSRF **, как мы увидим далее.

4.1. Внутренняя конфигурация

Наш API без сохранения состояния не может добавить токен CSRF, как наша конфигурация MVC, потому что он не генерирует никакого HTML-представления.

В этом случае мы можем отправить токен CSRF в файле cookie, используя CookieCsrfTokenRepository :

@Configuration
public class SpringSecurityConfiguration extends WebSecurityConfigurerAdapter {
    @Override
    public void configure(HttpSecurity http) throws {
        http
          .csrf()
          .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    }
}

Эта конфигурация установит файл cookie XSRF-TOKEN для внешнего интерфейса. Поскольку для флага HTTP-only мы установили значение false , внешний интерфейс сможет получить этот файл cookie с помощью JavaScript.

4.2. Интерфейсная конфигурация

С помощью JavaScript нам нужно найти значение файла cookie XSRF-TOKEN в списке document.cookie .

Поскольку этот список хранится в виде строки, мы можем получить его с помощью этого регулярного выражения:

const csrfToken = document.cookie.replace(/(?:(?:^|.*;\s*)XSRF-TOKEN\s*\=\s*([^;]*).*$)|^.*$/, '$1');

Затем мы должны отправлять токен на каждый запрос REST, который изменяет состояние API: POST, PUT, DELETE и PATCH.

Spring ожидает получить его в заголовке X-XSRF-TOKEN .

Мы можем просто установить его с помощью JavaScript Fetch API:

fetch(url, {
  method: 'POST',
  body: /* data to send */,
  headers: { 'X-XSRF-TOKEN': csrfToken },
})

5. Тест с отключенным CSRF

Со всем этим на месте, давайте проведем небольшое тестирование.

Давайте сначала попробуем отправить простой запрос POST, когда CSRF отключен:

@ContextConfiguration(classes = { SecurityWithoutCsrfConfig.class, ...})
public class CsrfDisabledIntegrationTest extends CsrfAbstractIntegrationTest {

    @Test
    public void givenNotAuth_whenAddFoo_thenUnauthorized() throws Exception {
        mvc.perform(
          post("/foos").contentType(MediaType.APPLICATION_JSON)
            .content(createFoo())
          ).andExpect(status().isUnauthorized());
    }

    @Test 
    public void givenAuth_whenAddFoo_thenCreated() throws Exception {
        mvc.perform(
          post("/foos").contentType(MediaType.APPLICATION_JSON)
            .content(createFoo())
            .with(testUser())
        ).andExpect(status().isCreated()); 
    } 
}

Здесь мы используем базовый класс для хранения общей вспомогательной логики тестирования — CsrfAbstractIntegrationTest :

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
public class CsrfAbstractIntegrationTest {
    @Autowired
    private WebApplicationContext context;

    @Autowired
    private Filter springSecurityFilterChain;

    protected MockMvc mvc;

    @Before
    public void setup() {
        mvc = MockMvcBuilders.webAppContextSetup(context)
          .addFilters(springSecurityFilterChain)
          .build();
    }

    protected RequestPostProcessor testUser() {
        return user("user").password("userPass").roles("USER");
    }

    protected String createFoo() throws JsonProcessingException {
        return new ObjectMapper().writeValueAsString(new Foo(randomAlphabetic(6)));
    }
}

Следует отметить, что запрос был успешно выполнен, когда у пользователя были правильные учетные данные безопасности — никакой дополнительной информации не требовалось.

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

6. Тест с поддержкой CSRF

Теперь давайте включим защиту CSRF и увидим разницу:

@ContextConfiguration(classes = { SecurityWithCsrfConfig.class, ...})
public class CsrfEnabledIntegrationTest extends CsrfAbstractIntegrationTest {

    @Test
    public void givenNoCsrf_whenAddFoo_thenForbidden() throws Exception {
        mvc.perform(
          post("/foos").contentType(MediaType.APPLICATION_JSON)
            .content(createFoo())
            .with(testUser())
          ).andExpect(status().isForbidden());
    }

    @Test
    public void givenCsrf_whenAddFoo_thenCreated() throws Exception {
        mvc.perform(
          post("/foos").contentType(MediaType.APPLICATION_JSON)
            .content(createFoo())
            .with(testUser()).with(csrf())
          ).andExpect(status().isCreated());
    }
}

Мы видим, как этот тест использует другую конфигурацию безопасности — ту, в которой включена защита CSRF.

Теперь запрос POST просто завершится ошибкой, если не будет включен токен CSRF, что, конечно же, означает, что более ранние атаки больше не возможны.

Кроме того, метод csrf() в тесте создает RequestPostProcessor , который автоматически заполняет допустимый токен CSRF в запросе для целей тестирования.

7. Заключение

В этой статье мы обсудили пару CSRF-атак и способы их предотвращения с помощью Spring Security.

Как всегда, код, представленный в этой статье, доступен на GitHub .

1. Обзор​

2. Две простые CSRF-атаки​

2.1. ПОЛУЧИТЬ примеры​

2.2. Пример POST​

2.3. Практическое моделирование​

3. Приложение Spring MVC​

3.1. Конфигурация безопасности Spring​

3.2. Конфигурация клиента​

4. Spring API без сохранения состояния​

4.1. Внутренняя конфигурация​

4.2. Интерфейсная конфигурация​

5. Тест с отключенным CSRF​

6. Тест с поддержкой CSRF​

7. Заключение​