Web安全我们常常在说的XSS漏洞到底是怎么回事？

Posted 2021-04-29 i春秋

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

这些年来，网站和浏览器都加强了针对跨站脚本攻击的安全防护力度，但仍发生了几次比较著名的病毒攻击，比如2014年黑客在Tweet桌面版上找到了一个XSS漏洞，可以在用户登陆时强制弹出恼人的提示框。

(在国内某知名网站上，每天都会看大关于XSS的漏洞提交）

去年早些时候，也是由于XSS漏洞，一条简单的评论就可能影响WordPress博客。那么我们来看看i春秋社区红人小宅带我们了解一下常常在说的XSS漏洞到底是怎么回事？

  目  录  

root@1~# XSS是怎么一回事？
root@2~# XSS的分类
root@3~# 简单理解同源策略（SOP）

  正  文  

root@1~# XSS是怎么一回事？

OK,既然我们要学习XSS这个玩意，总得对这玩意知根知底吧。（把他祖坟都挖出来……23333）。好了，不开玩笑了，在开始学习之前，我先说一下，大家一定要使用Firefox浏览器来测试与学习。

首先呢，我们来开启apache、mysql服务：

接下来，我们来到WEB根目录，创建一个xsstest.php文件，并编辑：

然后键入以下代码：

可能有人要问了，这分明是一个反射型XSS的DEMO，但是我写那么多代码干啥？

对，其实1行就行的。

但是，我不喜欢那种不贴近现实的DEMO。因为很多人不开窍，你要是给他学了那种DEMO，他自己就没法举一反三。

我也没办法，所以尽量做到贴近现实。
好了，我们来访问：
http://localhost/xsstest.php?title=A%20Website%20Ichunqiu

看看效果：

注意Title部分和正文content......的上面，我们不管给GET参数title赋值什么，这两处都是相同的。例如，我们为title赋值为Hello World，就是：

OK，确实是这样（汗一个，代码原本就这个意思，但是很多哥们跟我说看不懂，我很桑心....）接下来，我们假设我们输入了一个<p>a</p>会发生什么呢？我们试试：

我们看到title变成了<p>a</p>，正文的标题也成了<p>a</p>，但是为什么我们的html没有执行呢？

我们来看下源代码就懂了，如下：

view-source:http://localhost/xsstest.php?title=%3Cp%3Ea%3C/p%3E

我们可以看到，在title标签之间的<p>a</p>确实是<p>a</p>，但是在正文的h1标签之间的<p>a</p>却是：

<p>a</p>      

 好吧，这个正文处的<p>a</p>没被浏览器渲染，我们也就认了吧，因为在源代码里根本就不是<p>a</p>。但是这个title标签之间的<p>a</p>没被渲染是怎么一回事呢？

原因很简单，这是因为title标签之间的内容会被显示在浏览器的tab页内，你见过那个位置的<p>标签吗？你会说肯定没啊!那不久对了啊。好嘛，我们继续，那既然在title标签之间没法执行怎么办？

其实很简单啦，我们闭合</title>这样再在后面写代码不久行了吗？恩，不失为一个好办法，那就试试看：

艾码真的成了耶，好吧，其实我早就知道，呵呵。好了，现在大家有没发现一个问题？

为什么正文处的h1标签之间的内容会变成那样啊？
我们一看php源代码就知：

看到了吧，哈哈，因为在输出之前经过了一个htmlspecialchars()函数。。。所以被转义了。。导致变成可以渲染但是不能执行的代码（相信这样解释，大家应该能明白了。）

好了，到了这里，我们就能够初步的判断这个title(GET)存在反射型XSS漏洞。（管他什么型，这个我们下面再讲）。因为我们插入或者说注射进去的代码被执行了。

但是，这是HTML代码对于用户貌似没什么危害？最多算个bug嘛，怎么是漏洞呢？原因很简单，如果我们可以插入<script>...</script>标签或者以其他方式执行JS，那岂不是说，我们完全掌握了这样一个页面在前端的逻辑。

既然如此，我们就试试看能不能插入<script>...</script>标签吧，我们就那alert(/XSS/)来演示吧：

确实弹窗了，那童鞋们肯定又要问了，弹个窗又能有什么用呢？貌似还是没什么用吧？这就不然了，嘿嘿。

首先，在不讲其他知识的前提下，第一点就是可以用来钓鱼，例如：

http://localhost/xsstest.php?title=TITLE%3C/title%3E%3Cscript%3Evar%20a%20=%20prompt%28%27%E5%AF%86%E7%A0%81%E5%B7%B2%E7%BB%8F%E8%BF%87%E6%9C%9F%EF%BC%8C%E8%AF%B7%E9%87%8D%E6%96%B0%E8%BE%93%E5%85%A5%E5%AF%86%E7%A0%81%27%29;alert%28a%29;%3C/script%3E

看效果：

OK，至于怎么把密码传回来，这个后面再讲。我们现在就来总结下XSS是个啥情况。

首先，其实XSS是属于Code Injection的一种。就和SQL注射一样都是属于Code Injection漏洞，只是Injection的代码不同，SQL注射注射的是SQL语句，XSS则是注射的HTML和JS的语句。

目的都是一样的，妄图执行被注射的代码，来达到攻击者的目的。

root@2~# XSS的分类

接着，我们来说XSS的分类，刚才在root1的地方，大家可能就一直听我说反射型XSS了，对，这也是XSS分类的一种。

一般来说XSS普遍分为三种：

 1、存储型XSS

 2、反射型XSS

 3、DOM型XSS

这三种存在这很多异同之处，这个就只能靠大家自己去体会了。我只能给大家粗浅的讲一下了。

我们先说存储型的XSS，我们知道很多地方都有评论啊这些功能，如果我们键入评论并提交了，那么我们的评论内容存在什么地方了呢？

答案就是数据库，我们来数据库里建立一个xssDemo数据库，然后建立一个如下结构的表：

然后向其中插入一条数据：

然后，我们编写一个PHP的文件，代码如下：

我们接下来访问页面：

这就是存储型XSS，我们可以看到URL中没有传参，POST也没，这就是直接从数据库得到的数据然后渲染时执行。

这是最不受限制的一种XSS，因为反射型的XSS只能在Firefox下执行，IE和Chrome都已经有对应的解决方案了。但是存储型XSS则不受这个限制。而且更具有隐蔽性。因为代码不出现在URL里面。

接着，我们来说反射型的XSS，只是这次换成一行的Demo，嘿嘿。如下：

我们在浏览器上访问如下：

然后插入JS，如下：

相比存储型的XSS来说，反射型的XSS的利用方案就有不同，一般都会事先写好一个Payload，然后将链接发给用户，诱使用户访问含有Payload的URL达到JS代码执行的目的，而且仅仅限于Firefox，而且这种XSS在诱使用户点击的时候我们也不知道用户是否登录，从而导致不一定能读取得到Cookie。

接着我们来说DOM型XSS，这个其实是基于DOM执行的XSS，我们看如下Demo：

我们用浏览器加载下：

输入<h1>a</h1>，点击OK，如下：

我们可以看到，HTML成功执行了，那我们试试弹窗：

成功！嘿嘿，DOM-XSS和存储型XSS是一样的，不会因为浏览器的不同而存在不能执行的问题。

OK了，XSS的分类就这些了，我们来进入这篇paper的最后一个主题。

root@3~#简单理解同源策略(SOP)

OK，这篇paper的最后一个内容就是SOP了，所有讲XSS的书都有说SOP对于搞前端安全Very重要。所以，我们不得不提一下。

所谓SOP，其实是一个所有浏览器都遵循的规定。它限制着JS对浏览器上的一些元素的读写的权限。 正是因为有了SOP，浏览器的世界才不混乱，不然的话，我们iframe嵌入一个页面，直接在本地域就能直接读取嵌入的Iframe的域的cookie这些敏感内容了。而且如果没有SOP，我们甚至可以控制所有页面在客户端（浏览器）的逻辑。

我们试想这样的局面存在，那么Web的世界根本就不可能存在安全的概念，因为这个客户端都是“假”的，我们无法看到“真”的内容。每一步操作可能都是“攻击者”布下的陷阱，或许要一次点击就是灾难的来临。 所以SOP显得由为重要！Web世界的一切都离不开SOP！这一点绝对不用质疑的！

所以，我们今天就来先简单的学习一下SOP。 首先，SOP的规定换成“人话”来说就是： 不同域的客户端脚本在未授权的情况下不能读写别的域的资源。 其实这句话很好理解，但是其中的几个概念需要专门说一下，首先就是“同域”的概念。什么情况能被浏览器视为“同域”？

如下图（这经典的图，余弦哥哥的书里扣来的）：

这个就是同域和不同域的概念，很清晰了。至于客户端脚本，就是JS，VBS，AS这些能在浏览器这个容器里只能个的脚本。

至于明确授权的话就是有个HTTP响应头：
Access-Control-Allow-Origin

这个头的值将表明允许跨域的情况。然后就是在不同域的情况下两个不同的域的脚本无法读写对方的资源（明确授权情况除外）。

好了，这篇paper就到这里，有机会我们一起聊聊如何利用这些原理吧，嘿嘿。

点击

阅读原文

关注i春秋 精彩内容