WEB漏洞测试（二）——HTML注入 & XSS攻击

上一篇介绍了我们安装BWAPP来完成我们的漏洞测试

在BWAPP中，将HTML Injection和XSS做了非常详细的分类，那么为什么要将两个一起讲呢？归根结底，我觉得这两个分明是一个玩意，充其量是攻击的方式不一样。

我们先来介绍一下这两种漏洞的原理，简单说：当用户在输入框输入内容，后台对输入内容不做处理直接添加入页面的时候，用户就可以刻意填写HTML、JavaScript脚本来作为文本输入，这样这个页面就会出现一些用户加入的东西了。这是一种脚本注入（和CSDN发布文章时候的填写源码应该是类似的，CSDN填写源码时候可以搞些链接，假设这些链接链到恶意网站，甚至不写链接直接Script脚本？这样是不是很恐怖？）



看这个例子，下一行文字会把输入的xs打出来，那么假如我填写的是一个连接？



点击这个Click Me就跳到百度去了。

再假如我填写的是一个script标签下的东西，是不是更加恐怖？我们知道浏览器是不对cookie做过多防护的，如果这种手段配合CSRF攻击（不好意思先让这玩意提前出场一下），细思极恐啊。

当然有些稍微有点脑子的网站会屏蔽script标签的输入，但是我们大可以利用类似于

<img src=1 onerror=alert(1) />

这样的语句

说了那么多，我们发觉没有，好像原理并不复杂，为什么BWAPP上可以分出那么多种类呢。其实吧这款软件在于展示各类漏洞，有些漏洞原理虽然一样，但是伴随着不同的攻击和防护也是有着截然不同的效果的。

比如HTML注入和XSS攻击就是对注入的是html还是js做了分类（这个分类略蠢），然后对于用的是get请求还是post请求、json还是xml、ajax还是表单做了分类（比前一个略好点不过感觉也挺蠢）。其实众多分类中较为有点用处的是反射型和存储型。

其实这种分类也没太高明的地方，甚至不需要举例，就是一个结果直接呈现，一个是存到数据库里面。我们前面那个例子就是反射型的，但是显然这种攻击没有太大效果，因为攻击方和效果呈现在同一台机子同一个浏览器同一次浏览；而存储型就不同了，用于存入数据库，因此这些攻击脚本是长时间存在的，比如微博朋友圈等等。

其实相比起这些可有可无的分类，对于xss的防护措施才是比较重要的，我们之前说过很多后台会过滤<script>标签，但是可以用img标签来完成一些特殊的处理，还有些过滤不够完善的，可以用类似<scr<script>ipt>这样的标签来过滤，就是当吧script标签过滤掉了以后，原本无意义的语句变为了script标签。

所以相比起过滤script标签，我们可以采用更加高明的过滤'<''>''&'等符号。

这里有一个问题啊，我们都知道浏览器会解释上述几个符号，那假如我想在浏览器中显示一条html代码该怎么办？

事实上html是定义了几个特定符号专门用来表示这几个符号的，比如用&来代替&符号，比如我们这篇文章标题中的&符号，在文章列表中就会显示出&

浏览器给特定符号一些特定的文本表示，那我们就可以用这种手段去过滤，我们将BWAPP的等级跳到medium，选择HTML Injection - Reflected (GET)进行hack：



我们在输入框填入<a href=http://www.baidu.com>Click Me</a>，发觉代码并没有像我们想象中这样呈现出来，而是完整地被显示在了下面，我们打开BWAPP的源码，通过主目录下的bugs.txt找到bug对应的源码文件，发觉medium调用了xss_check_1方法：



我们发觉这里将输入的内容中的<>符号给替换成了<和>，很明显在这种情况下标签就变得没用了。

但是我们也看到了，在注释中充分诠释了这种方案的破解之法，这种方案必须要进行urldecode，所以我们只需要一开始就把<>符号encode之后的内容输入即可：

输入如下

%3ca+href%3dhttp%3a%2f%2fwww.baidu.com%3eClick+Me%3c%2fa%3e



在这种情况下，我们将防护措施跳到high，发觉最高的防护措施完美解决了这个问题。

function xss_check_3($data, $encoding = "UTF-8")
{

// htmlspecialchars - converts special characters to HTML entities
// '&' (ampersand) becomes '&'
// '"' (double quote) becomes '"' when ENT_NOQUOTES is not set
// "'" (single quote) becomes ''' (or ') only when ENT_QUOTES is set
// '<' (less than) becomes '<'
// '>' (greater than) becomes '>'

return htmlspecialchars($data, ENT_QUOTES, $encoding);

}由于这个bwapp是php写的，所以他利用了php的高级转义函数htmlspecialchars，这个函数的功能和我们之前说的medium原理其实类似，唯一的优势是避开了urldecode。
那么我们提出了两个问题：1）非php（如java）中是否有类似函数；2）这个函数防护下的后台是否可以攻击。

首先第一点，答案是肯定的，原理都知道了，只是实现一下谁不行？

随便举个实现的第三方库：org.apache.commons.lang这个包：

StringEscapeUtils.escapeHtml方法即可。

然后第二个问题，这个问题其实很难说怎么回答，应该分为两个方面：

1）htmlspcialchars这个函数本身对xss的限制目前为止似乎是没有办法破解的，因为他完全利用了转义，换句话说直接攻破了xss的原理

2）虽然说这个函数基本上完克了xss，但是攻击防护本来就是相生相克的，看谁棋高一着，虽然我们没法用xss直接打破htmlspcialchars，但是我们既可以使用别的攻击方式去解决，也可以利用程序员对于htmlspcialchars的使用不当去可以绕开甚至利用这个函数，我们可以看看知乎对这个问题的回答https://www.zhihu.com/question/27646993

在这个回答中，我们发觉如果开发人员把htmlspcialchars用在不当地方（如script标签中间），那这层防护和没有一样（本来是用来防止script标签的，结果自己把它放在script标签里面，贼蠢）

所以我们需要明白，不存在什么防护都能破解的攻击，也不存在什么攻击都能防御的防护，攻击和防护本来就是程序员和恶意用户斗智斗勇的一场博弈，谁棋高一着谁就胜利。作为
4000
一名开发人员，我们不能用这些攻击手段去做违法的事情，但是我们可以研究这些攻击去完善我们的防护，就比如这里，我们知道了如何解决xss攻击，但是如何讲解决方案用在恰当的地方，这需要我们日积月累去积累经验的。

注意：本博客只为学习和防护所用，严禁用于违法途径，否则后果自负