本文将详细说明如何分析春天对CSRF的预防。文章内容质量较高，边肖将分享给大家参考。希望大家看完这篇文章能有所了解。
什么是 CSRF
跨站点请求伪造。经典的一幕是：
1）受害者首先登录了银行网站
2）用户没有 longout 的情况下
3）用同一个浏览器访问了“坏”网站
4）“坏”网站有一个向银行网站提交业务请求的页面
5）诱使用户发送这个请求。
这个场景背后的逻辑：
实际上利用了XSS漏洞，该漏洞可以自动触发步骤4和步骤5，而无需受害者参与javascript。
00-1010在这里，我们把浏览器等同于用户。有些数据对用户是可见的，有些数据由浏览器自动处理和发送，但用户不知道这些数据(如SessionId)。
网站将sessionId以cookie的形式发送给浏览器(set-cookie)，浏览器每次请求时都会自动携带cookie。
在上述场景的第五步中，虽然“不良”表单不是来源于银行网站的页面，而是在第三方网站的页面上，但是浏览器发现目标地址是银行网站，所以会自动带来对应的cookie，比如JSESSION会随之发送。从服务器的角度来看，步骤4的数据和正常数据没有区别，因为这个业务请求将被执行。
归根结底，这个CSRF问题是早期cookie的简单设计造成的，与现代浏览器的同源策略等安全机制不同步。
00-1010一个是主流的“同步器令牌模式”方法，一个是逐渐主流的“SameSite属性”。
1）SameSite Attribute的这种方法易于实施和理解。先说说吧。
在服务器上使用cookie的SameSite属性可以禁止浏览器在从外部站点发送请求时携带cookie。例如，以下cookie不会放在由第三方网页发起的针对银行网站的请求中。这自然解决了上面的CSRF问题。SameSite也可以设置为“严格”。
set-cookie : jsessionid=随机化；domain=bank . example.com；安全；HttpOnlySameSite=Lax
2）Synchronizer Token Pattern
这种解决方案的原理是，我们都从浏览器向请求发回一个随机数，下次浏览器请求服务时，它需要将这个随机数带进标头或表单中。这个随机数就是csrf令牌。这是泉安采用的方式。
这个方法之所以能阻止CSRF，是因为sessionId来自cookie，而csrf token来自header或者form。相当于分别在两条不同的路径上传递.
Spring Security模块生成csrf令牌后，可以放在两个地方。默认情况下，Spring随机数与sessionId相关联，并放置在会话中。另一种方法：将随机数放入cookie中。
00-1010和会话之间的关联很容易理解。下次浏览器发送请求时，服务器可以将从报头或表单中提取的csrf令牌与会话中的随机数进行比较来判断。
00-1010用cookie保存csrf怎么样？如果csrf令牌通过cookie发送给浏览器，这个随机数不会像JSESSIONID一样被浏览器自动传输回服务器吗？
是的，这个通过cookie发送到浏览器的csrf令牌肯定会被浏览器发送回服务器，我们已经用这个来“保存”csrf令牌。之所以使用基于Cookie的方法，是因为前端可以使用javascript获取csrf token，用于前端和后端的分离，并将此token作为下一个请求的标头参数或表单参数传递给服务器。服务器需要做的是通过比较cookie和头/表单中的csrf令牌来判断请求是否是CSRF请求。
以下代码设置使用cookies保存csrf令牌。当使用cookie传输令牌时，您需要将cookie的HttpOnly属性设置为false，以便javascript可以读取该值。
@EnableWebSecuritypublic类WebSecurityConfig扩展了websecurityconfiguradapter { @ Override protected void configure(Httpsecurity http){ http。csrf(csrf - csrf。csrfTokenRepository(cookiesrftokenrepository . withtponlyfalse())；}}
这里将分享如何分析Spring对CSRF的防范措施。希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/148965.html
