我使用Spring并启用了带有HttpSessionCsrfTokenRepository的csrf,我清楚地知道客户端是否将csrf令牌作为_csrf参数或X-CSRF-TOKEN头作为请求Spring拾取令牌并使用使用GenerateToken(HttpServletRequest request)
生成的令牌进行验证,但我的问题是Spring如何在内部做到这一点。我这个问题的原因是:
1.我有一个Rest POST调用,它接受凭据并验证用户的身份。但是由于我想在rest调用中添加一个csrf令牌作为安全层,我想在帖子正文中添加它以防止csrf令牌泄漏。
因此,如果我知道Spring Security如何在内部过滤这些令牌,那将是有帮助的。我修改了Spring留档,但它主要是我们如何在具有隐藏字段或元标记的表单中使用CSRF令牌以及带有标题的Ajax调用。
我也想听听对我的设计的任何评论,如果它是好的,有令牌的主体(我确信,因为它不会是一个简单的url参数泄漏令牌),或者我应该有它在头。我只是不想倾向于使用头,只是因为它的简单。寻找最佳解决方案。
请给我一些光。
如果您想深入研究,SpringCsrfTokenRepository有多种实现。例如:
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它的好处(更安全-可能是?)保持令牌在标题上,因为我能想到的原因很少…
>
您不能在GET请求的主体上设置令牌。您希望所有endpoint保持一致(您今天可能不需要它,但事情变化非常快)
明天如果你想改变你的Auth模型,你不想改变你的请求体。当请求体改变时,你违反了与客户的合同
如果您将auth模型更改为授权服务器,您可以在服务之前添加代理服务器(如ngnix?),并将其称为auth-proxy。您可以将所有与安全相关的事情留给此auth-proxy,它将检查标头并为您进行验证。您不希望代理查看您的请求主体,您可以专注于您的业务实现
这只是我根据我的经验得出的看法。