DVWA通关攻略之跨站请求伪造

1. CSRF 跨站请求伪造

跨站请求伪造（CSRF：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟持用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作。主要利用 Cookie 机制，cookie机制是一种会话机制，浏览器用 cookie 来存储少量数据，作用之一是记录用户在网站上的登录信息，一段时间内维持登录状态，便于用户对网站的访问，不需要每次访问同一个网站、访问后每次点击链接都需要验证身份时都输入账号密码。因为用户曾经认证过的网站，用户的浏览器中存有 cookie，用户访问恶意链接时，被设计隐含的访问曾认证过的网站，访问时会自动携带上之前存的 cookie，服务端会认为是用户自己访问的，成功访问导致 CSRF 攻击。 攻击者盗用了用户的身份，以用户的名义发送恶意请求。CSRF能够做的事情包括：以用户名义发送邮件，发消息，盗取用户的账号，甚至于购买商品，虚拟货币转账，造成个人隐私泄露以及财产安全。
由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

2.漏洞场景

假如一家银行用以运行转账操作的URL地址如下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那么，一个恶意攻击者可以在另一个网站上放置如下代码：

 <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。通过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户浏览器，让其以用户的名义运行操作。

3. 实验演示

访问 http://127.0.0.1/DVWA/login.php登录 DVWA，账号密码为 admin/password。
在DVWA页面左侧选择 CSRF。目标是通过 CSRF 让目标用户没有意识到的情况下，修改自己的密码为攻击者指定密码。

3.1.low

DVWA Security设置为low,即开发者没有采取任何方法防止 CSRF。意味着可以精心制作链接来完成特定行为，这里是改变用户的密码。然后通过基本的社会工程学，使得目标点击制造的链接，或仅仅访问特定页面来触发行为。
首先是目标用户登录网站后在修改密码页面修改密码。假如用户想修改密码为 1234。

两个输入框都输入 1234，然后点击 change。

修改成功。此时 admin 密码为 1234。在 Test Credentials 中验证。

账号密码：admin/1234。验证成功。
上面点击 change 后的 URL 为

http://127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=1234&password_conf=1234&Change=Change#

分析发现输入密码就在 URL 中通过 get 方式传递。
攻击者会把以上 URL 中的密码修改为攻击者自己想设置的密码。例如 789。 即URL变为

http://127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=789&password_conf=789&Change=Change#

然后攻击者设法让目标用户访问以上链接。比如通过社会工程学的方式，给目标用户发送邮件，邮件包含这个链接；为了隐藏 URL 中的信息还可以使用短链接；等等。
这里模拟目标用户访问了以上 URL，即通过同一个浏览器访问以上 URL。

显示密码修改成功。此时的账号密码应该为 admin/789。而目标用户没有意识到自己点击一个链接后密码已经被重新设置，还认为账号密码为自己设置的 admin/1234。
在 Test Credentials 中验证。

验证成功。

此时账号密码为 admin/789。再验证目标用户记忆中的账号密码 admin/1234。

显示密码错误。至此。在 low 级别的 CSRF 攻击完成。通过设法使目标用户点击一个设计好的链接，在目标用户未意识到情况下，修改了其密码。以后攻击者掌握了目标用户登录该网站的账号密码，可以做很多事情了，开脑洞！！！此外， CSRF最关键的是利用受害者的cookie向服务器发送伪造请求，所以受害者之前用的是IE浏览器登录的系统，而后通过谷歌浏览器浏览该恶意链接，攻击是不会触发的，因为请求谷歌浏览器没有存储受害者登录cookie，而会直接跳入登录界面。

3.2. Medium

DVWA Security设置为Medium，按照 low 即便方式设计 URL 后，让目标用户访问，会报错如下。

查看源码。

发现通过 stripos 函数对 HTTP 请求的 Referer 头进行了包含性验证。stripos(a,b)返回 b 在 a字符串的开始位置，字符串起始位置为0，如果未发现 b，则返回false。代码检查了保留变量HTTP_REFERER（http包头部的Referer字段的值，表示来源地址，
即链接到当前页面的前一页面的url链接地址）是否包含SERVER_NAME（http包头部的 Host字段表示要访问的主机名）。直接复制正常访问的 URL,修改 URL 中修改的密码后访问，由于没有前一页面，会没有 referer，攻击失败。通过把恶意 URL 包含在其他页面中诱导目标用户点击，referer 值是其他页面的值，不一定包含 Host 字段要访问的主机名，攻击也失败。针对这一过滤规则，我们只要想办法绕过，那么我们后面的代码和low级别的基本都一样。可以通过更改页面文件名来绕过stripos函数。绕过方法：假如服务器地址为127.0.0.1，即为SERVER_NAME，我们只需要把我们构造的恶意页面文件名改为127.0.0.1.html，HTTP_REFERER就会包含127.0.0.1.html,就可以绕过stripos了。127.0.0.1.html,内容如下。

 <img src="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=5678&password_conf=5678&Change=Change#" border="0" style="display:none;"/> <h1>hello gay<h1> <h2>Your password has been changed!!!<h2>

就本地做 DVWA 实验而言可以通过 burp 抓包后手工修改，

添加 Referer 内容， Referer: http://127.0.0.1/DVWA/，修改密码为攻击者想设置密码，例如 123。

修改成功。
或者 burp 抓包后，点击 Action->Engagement tools->Generate CSRF Poc

在弹出页面把密码改为 12， 点击 Copy HTML

新建文件命名为 127.0.0.1.html。把复制的内容粘贴到其中，保存。使用浏览器访问后点击 submit 即可。

3.3. High

DVWA Security设置为High，通过查看源代码发现，新添加了一个每次访问都不同的 user_token 字段，来阻止恶意访问。在 DVWA 本地实验中可以通过 burp 抓包后重放攻击实现。首先 burp 抓包。然后发送到 repeater，修改密码为我们设置的值，点击 send 即可。但是在实际中怎么及时获得目标用户修改密码的数据包呢？可以配合 XSS 来实现。想办法直接把脚本文件偷偷上传到受害者的服务器，然后引诱其访问自己服务器的链接，至于怎么上传，可以…还可以使用 burpsuit 的 CSRF Token Tracker 插件。

3.4. Impossible

DVWA Security设置为Impossible Level。

Impossible级别的源码中也使用验证user_Token和原始密码来防止CSRF，如果没有当前密码无法进行修改密码，基本杜绝了 CSRF 攻击。db->prepare采用的是PDO模式，防止SQL注入。

4. 防御措施

检查Referer字段
HTTP头中有一个Referer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以上文银行操作为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.examplebank.com之下。而如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.examplebank.com之下，这时候服务器就能识别出恶意的访问。这种办法简单易行，工作量低，仅需要在关键访问处增加一步校验。但这种办法也有其局限性，因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。
添加校验token
由于CSRF的本质在于进行敏感操作时用户每次发送的请求都完全相同，攻击者就把这样的请求进行封装包裹，欺骗用户去访问自己设置的链接，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中，其内容是一个伪随机数。当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误，拒绝这个可疑请求。
增加二次验证机制
在敏感操作时，不再直接执行请求，而是需要再次验证用户口令或者验证码。
Set-Cookie:SameSite
禁止第三方网站带Cookies，可以在响应头Set-Cookie设置SameSite属性，表示Cookie为同源网站而非第三方网站。
…等等。