Как пружина внутренне проверяет токен csrf с параметром _csrf или заголовком X-CSRF-TOKEN? - PullRequest
Новая
       10

Как пружина внутренне проверяет токен csrf с параметром _csrf или заголовком X-CSRF-TOKEN?

0 голосов
/ 29 августа 2018

Я использую spring и включил csrf с HttpSessionCsrfTokenRepository, я четко знаю, отправляет ли клиент токен csrf в виде параметра _csrf или X-CSRF-TOKEN для запроса, а весна выбирает токен и проверяется токеном, который был генерируется с помощью generateToken(HttpServletRequest request) Но мой вопрос в том, как весна делает это внутренне. Моя причина этого вопроса:

1.У меня есть вызов Rest POST, который принимает учетные данные и проверяет личность пользователя. Но так как я хочу добавить токен csrf в остальные вызов как слой безопасности, я хотел бы добавить его в теле поста для предотвращения утечки токена csrf.

Так что, если я знаю, как Spring Security внутренне фильтрует эти токены, было бы полезно. Я пересмотрел весеннюю документацию, но в основном мы можем использовать токен CSRF в форме со скрытым полем или метатегами и вызовом Ajax с заголовком.

И я также хотел бы услышать любые комментарии о моем дизайне, если будет полезно иметь токен в теле (я убежден, потому что это не будет простым параметром url для утечки токена), или я должен иметь его в заголовок. Я просто не хочу использовать заголовок только потому, что он прост. В поисках лучшего решения.

Пожалуйста, пролите немного света.

1 Ответ

0 голосов
/ 29 августа 2018

Весной есть несколько реализаций для CsrfTokenRepository, если вы хотите разобраться в этом. например:

https://github.com/rwinch/spring-security/blob/master/web/src/main/java/org/springframework/security/web/csrf/HttpSessionCsrfTokenRepository.java

https://github.com/rwinch/spring-security/blob/master/web/src/main/java/org/springframework/security/web/csrf/CsrfFilter.java

https://github.com/rwinch/spring-security/tree/master/web/src/main/java/org/springframework/security/web/csrf

https://docs.spring.io/spring-security/site/docs/4.2.7.RELEASE/apidocs/org/springframework/security/web/csrf/CookieCsrfTokenRepository.html

https://docs.spring.io/spring-security/site/docs/4.2.7.RELEASE/apidocs/org/springframework/security/web/csrf/CookieCsrfTokenRepository.html

IMO хорошо (безопаснее - может быть?) Держать токены в заголовке по нескольким причинам, о которых я могу думать ..

  1. Вы не можете установить токен на теле для вашего запроса GET. Вы хотите быть последовательными во всех своих конечных точках (вам это может не понадобиться сегодня, но все меняется очень быстро)

  2. Завтра, если вы хотите изменить свою модель аутентификации, вы не хотите менять тело запроса. при изменении тела запроса вы расторгаете договор с клиентами

  3. Если вы измените свою модель авторизации на сервер авторизации, вы можете добавить прокси-сервер (например, ngnix?) Перед вашим сервисом, и пусть он будет называться аутентификационным прокси-сервером. Вы можете оставить все вещи, связанные с безопасностью, этому auth-прокси, и он проверит заголовок и выполнит проверки для вас. Вы не хотите, чтобы прокси просматривал тело вашего запроса, и вы можете сосредоточиться на реализации вашего бизнеса

  4. Тело запроса полностью связано с вашим бизнесом, поэтому вы можете сосредоточиться на нем, а не на вопросах безопасности в вашем теле.
  5. Каждый раз, когда вы создаете новый Запрос на новую конечную точку, вы не хотите продолжать добавлять токены во всех запросах

Это только мое мнение, основанное на моем опыте.

...