标签：Mallory 跨站 csrf 请求 网站 CSRF 攻击者 Bob 伪造

一  概念

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

 

 

二  过程

1  受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。

 

2  通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。

 

3  黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。

但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。

 

4  这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。

 

5  当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。

 

6  但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。

这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

 

 

 

三  基本过程图解如下：

 

 

 

 

 

四  总结

用户和网站通过正常登陆，建立了信任关系，在这种信任关系的有效期内，用户通过广告等形式进入了攻击者的网站，攻击者会在自己的网站内访问与用户建立的信任关系的网站的某些敏感操作，而此时，用户和网站还在信任有效期内。

也可以通过类似xss的方式，上传图片之类的东西，src=某个请求，用户进入这个网站之后会发送这条请求。

并不是只有get请求才能被csrf，攻击者同样可以通过表单完成一次post的csrf攻击。

 

 

 

五   防御

1. 判断referer：并不好，

见[花式绕过csrf技巧]

(https://www.ohlinge.cn/web/csrf_referer.html?utm_source=tuicool&utm_medium=referral)。

 

2. jwt，比较常用，后端返回token，localstorage是有跨域限制的，其他域名无法访问信任域的缓存，每次请求在请求上带上token。

标签：Mallory,跨站,csrf,请求,网站,CSRF,攻击者,Bob,伪造
来源： https://www.cnblogs.com/softwarelanguagebs/p/10755489.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。