| CSRF攻击及防御 | 您所在的位置：网站首页 › 防止csrf攻击方法 › CSRF攻击及防御 |
CSRF攻击及防御
|
1.1 概念
跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。 1.2 攻击细节跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。 攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义运行操作。 1.3 攻击原理 用户打开浏览器，访问受信任银行网站，输入用户名和密码请求登录网站；在用户信息通过验证后，银行网站产生Cookie信息并返回给浏览器，此时用户登录网站成功，可以正常发送请求到网站；用户未退出银行网站之前，在同一浏览器中，打开一个TAB页访问其他网站B这时候网站B 已被黑客注入诱导信息，加入是一张图片,图片地址指向 src=”http://bank.example/withdraw?account=bob&amount=1000000&for=黑客 点击之后转账给黑客这个账户浏览器在接收到这些攻击性代码请求后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，根据用户的Cookie信息以C的权限处理该请求，导致来自黑客请求恶意代码被执行。
1.4 防御措施
1）检查Referer字段
根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。 仍存在隐患： 1.可以篡改 Referer 值 2.用户自己可以设置浏览器使其在发送请求时不再提供 Referer 2）添加校验token 用户访问某个表单页面。服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。在页面表单附带上Token参数。用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
这个Token的值必须是随机的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。 token的另外解决措施： 跳转页面前生成随机token，并存放在session中。form中将token放在隐藏域中，保存时将token放头部一起提交。获取 token，与session中的token比较，一致则通过，否则不予提交。生成新的token，并传给前端。 3）验证码验证 4）在HTTP 头中自定义属性并验证这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。 5）利用spring-security解决CSRF问题利用spring-security解决CSRF问题 参考资料百度百科 https://www.jianshu.com/p/ffb99fc70646 https://www.jianshu.com/p/5096b39c0020 这个博客的排版太舒服了吧，讲的也挺好 |
也就是说，服务器会验证客户端的请求来源，如果是本网站请求的则响应，否则不响应【本文地址】