WEB常见漏洞之CSRF（基础原理篇）

0x01漏洞概述

黑客利用已经登录的用户，诱使其访问或者登录某个早已构造好的恶意链接或者页面，然后再用户毫不知情的情况下，以用户的名义完成了非用户本意的非法操作。

这种攻击我们也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF,是一种对网站的恶意利用行为。

与XSS攻击相比，CSRF攻击往往不大流行（因此对其防范的资源也相当稀少）和难以防范。

浏览器同源策略

1995年，同源策略由Netscape公司引入浏览器。目前，所有浏览器都实行这个策略。最初，他的含义是指：

A网页设置的Cookie，B网页不能打开，除非这两个网页“同源”。所谓同源指的是“三个相同”

协议相同域名相同端口相同

同源策略目的

Cookie包含隐私（比如存款总额），这些信息就会泄露。更可怕的是，COokie往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户。

场景：A网站是一家银行，用户登录以后，又去浏览其他网站，如果其他网站可以读取A网站的Cookie，会发生什么？

为了保证用户信息的安全，防止恶意的网站窃取数据。

限制范围

共有三种行为收到限制：

cookie、LocaIStorage和lndexDB无法读取DOm无法获得AJAX请求不能发送

虽然这些限制是必要的的，但是有些合理的用途也受到影响。
例如：
同一个站点的不同域名不能共享COOKIE；bobao.360.cn/anquanke.com
cookie作用域
Cookie两个重要属性
1.Domain：当前要添加的cookie的域名归属，如果没有明确指明则默认为当前域名，www.text.com添加的域名模式就是www.test.com。
2.Path：当前要添加的Cookie的路径归属，如果没有明确指明则默认为当前路径，访问www.test.com/java/hotspot.html添加的Cookie的默认路径就是/java/，访问blog.text.com/java/hotspot.html生成的COokie的路径也是/java/。
浏览器提交Cookie需要满足以下两点：
1.当前域名或者父域名下的COokie2.当前路径或父路径下的Cookie0x01漏洞概述

0x02CSRF分类

CSRF(Cross-Site Request Forgery)，跟XSS漏洞攻击一样，存在巨大的危害性。

你可以这么来理解:攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等

1.GET类型的CSRF

1.GET类型的CSRF

仅仅须要一个HTTP请求。就能够构造一次简单的CSRF。

样例：

银行站点A：它以GET请求来完毕银行转账的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000 

危险站点B：它里面有一段HTML的代码例如以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先。你登录了银行站点A，然后访问危险站点B，噢，这时你会发现你的银行账户少了1000块。

为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。

在访问危险站点B的之前。你已经登录了银行站点A，而B中的一个合法的请求，但这里被不法分子利用了

所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了

原本这是：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

结果银行站点服务器收到请求后，觉得这是一个更新资源操作（转账操作），所以就立马进行转账操作。

2. POST类型的CSRF

在CSRF攻击流行之初，曾经有一种错误的观点，认为CSRF攻击只能由GET请求发起。因此很多开发者都认为只要把重要的操作改成只允许POST请求，就能防止CSRF攻击。

这样的错误观点形成的原因主要在于，大多数CSRF攻击发起时，使用的HTML标签都是<image>、<iframe>、<script>等带“src"属性的标签，这类标签只能够发起一次GET请求，而不能发起POST请求。

而对于很多网站的应用来说，一些重要操作并未严格地区分GET与POST，攻击者可以使用GET来请求表单的提交地址。比如在PHP中，如果使用的是$_REQUEST，而非$_POST获取变量，则会存在这个问题。

对于一个表单来说，用户往往也就可以使用GET方式提交参数。比如以下表单:

<form action=" / register" id="register" method="post" ><input type=text name="username" value="" /><input type=password name="password" value="" /><input type=submit name="submit" value="submit" /></form>

用户可尝试构造一个GET请求
http: //host/register?username=test&password=passwd

来提交，若服务器端未对请求方法进行限制，则这个请求会通过。

如果服务器端已经区分了GET与POST，那么攻击者有什么方法呢?对于攻击者来说，若干种方法可以构造出一个POST请求。

最简单的方法，就是在一个页面中构造好一个表单表单，然后使用JavaScript自动提交这个表单。比如，攻击者在www.b.com/test.html中编写如下代码：

<form action="http: / / www . a.com/register" id="register" method="post" ><input type=text name="username" value=""/><input type=password name="password" value=""/><input type=submit name="submit" value="submit"/></ form><script>var f = document.getElementById ( "register");f.inputs [0].value = "test";f.inputs [1].value = "passwd" ;f.submit ();</script>

攻击者甚至可以将这个页面隐藏在一个不可见的iframe窗口中，那么整个自动提交表单的过程，对于用户来说也是不可见的。

在2007年的Gmail CSRF漏洞攻击过程中，安全研究者pdp展示了这一技巧。首先，用户需要登录Gmail账户，以便让浏览器获得Gmail的临时Cookie。

用户登录Gmail

然后，攻击者诱使用户访问一个恶意页面。

攻击者诱使用户访问恶意页面

在这个恶意页面中，隐藏了一个iframe，iframe的地址指向pdp写的CSRF构造页面。

http: //www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/form-data&_action=https%3A//mail.google.com/mail/h/ewtljmuj4ddv/%3Fv%3Dprf&cf2_emc=true&cf2_email=evilinboxmailinator.com&cfl_from&cfl_toucf1_subjicf1_has&cfl_hasnotscf1_attach=truestfi&S=z&irf=on&nvp bu_cftb=Create%20Filter

 这个链接的实际作用就是把参数生成一个POST的表单，并自动提交。
由于浏览器中已经存在Gmail的临时Cookie，所以用户在iframe中对Gmail发起的这次请求会成功―—邮箱的Filter中会新创建一条规则，将所有带附件的邮件都转发到攻击者的邮箱中。

恶意站点通过CSRF在用户的Gmail中建立一条规则。

如果上述例子看得还是有点懵逼，那再举一个例子：

在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。

/coures/user/handler666buy.php</font>

通过提交表单，buy.php处理购买的信息，这里的666为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容。
<form action=/coures/user/handler/666/buy method=POST><input type="text" name="xx" value="xx" /></form><script> document.forms[0].submit(); </script>

当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为666的视频，从而导致受害者余额扣除。




0x03CSRF漏洞挖掘

1、最简单的方法就是抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞。

2、如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

3、随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下:

使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。

如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。




0x04原理总结

一个CSRF漏洞攻击的实现，其需要由三个部分来构成

有一个漏洞存在（无需验证、任意修改后台数据、新增请求）；伪装数据操作请求的恶意链接或者页面；诱使用户主动访问或登录恶意链接，触发非法操作；

第一部分

漏洞的存在

关键字：跨站请求漏洞

如果需要CSRF攻击能够成功，首先就需要目标站点或系统存在一个可以进行数据修改或者新增操作，且此操作被提交后台后的过程中，且未提供任何身份识别或校验的参数。后台只要收到请求，就立即下发数据修改或新增的操作；

以上漏洞情况的存在，出现比较多的场景有用户密码的修改、购物地址的修改或后台管理账户的新增等等操作过程中。

第二部分

漏洞利用的伪装

关键字：伪装请求

CSRF漏洞存在 了，如果需要真正的被利用，还需要对“修改或新增”数据操作请求的伪装，此时恶意攻击者只要将伪装好的“数据修改或新增”的请求发送给被攻击者，或者通过社工的方式诱使被攻击者在其cookie还生效的情况下点击了此请求链接，即可触发CSRF漏洞，成功修改或新增当前用户的数据信息，如修改当前用户的密码，又或者是当前用户为后台管理员，触发漏洞后新增了一个后台管理员。

第三部分

用户非本意的操作

关键字：非本意操作

当前用户在不知情的情况下，访问了黑客恶意构造的页面或在链接，即在非本意的情况下完成黑客想完成的“非法操作”，实现了对当前用户个人信息的恶意操作。

小结

构造一个恶意链接或者html页面

CSRF漏洞的目的：利用已存在的漏洞构造了一个“恶意链接”或“HTML”页面，然后诱使用户点击触发此漏洞

目标站点存在一个漏洞（CSRF），攻击者利用此类漏洞伪装了 一个链接或者html页面，诱使被攻击者在登录的情况下（即当前cookie有效的情况下）点击了此伪装请求，随后在用户不知情的情况下完成了对当前用户数据的修改或者新增操作，而被修改的信息可能是用户的密码、关键信息又或者新增后台管理员等。




0x05知识星球