如何为开发人员演示DOM型XSS漏洞利用过程

我的工作是设法让开发人员编写出安全的代码，而安全教育则是实现该目标的关键部分。虽然有很多方法可以实现安全教育的目的，但是，如果为开发人员直观展示攻击者是如何利用软件漏洞发动攻击的话，他们一定会对安全隐患带来的危害留下深刻的印象，从而提高其责任心。

在做这些演示时，我发现了两个具有相似XSS漏洞的测试站点：Altoro Mutual和OWASP Juice Shop。事实上，如果只是从表面上看的话，这些漏洞完全相同，但是它们是有区别的：Altoro Mutual网站存在的是反射型XSS，而Juice Shop网站的漏洞则是DOM型XSS。事实证明，在企业环境中演示DOM型XSS要更加方便一些，同时，这种类型的漏洞通常对攻击者更有利。

在这篇文章中，不仅解释了为什么要向开发者演示黑客攻击，同时，还讲解了如何炫酷的演示针对OWASP Juice Shop的DOM型XSS漏洞的攻击过程。这个过程中，需要用到一个恶意服务器，为了节约读者的时间，这里提供了现成的代码和示例服务器。在这个攻击场景中，攻击者将利用恶意服务器窃取受害者的cookie，并从中获取受害者的密码。 

关于XSS

本节内容适合不熟悉XSS的读者，对于已经熟悉该漏洞的读者，可以跳过。

简单来说，利用XSS漏洞，攻击者可以让自己的JavaScript代码在别人的网站上执行，特别是从一个或多个受害者用户浏览器中执行。

据我所知，最著名的XSS攻击当属MySpace蠕虫“Samy is my Hero”。当年，Samy Kamkar在MySpace上创建了一个脚本，该脚本不仅会迫使所有访问其个人页面的人加他为好友，还会在其个人页面的 "我的英雄" 分类下加上一句话："but most of all, samy is my hero"，并将该脚本复制到受害者的MySpace个人资料中。不到20个小时，就有100万个用户请求加Samy为好友。

Samy蠕虫是持久型XSS，这意味着该脚本将永久存储在数据库中。持久型XSS漏洞是最糟糕的，因为所有访问该站点的MySpace用户都会被感染。
除了持久型XSS之外，还有反射型和DOM型XSS漏洞，在本文中，我们将对这两种类型的漏洞进行深入的分析。由于这两种类型的漏洞需要设法哄骗受害者通过点击来触发漏洞（即社会工程），所以，在危险性方面它们要弱一些，然而，就像大家将要看到的那样，一旦受到它们的攻击，后果将会非常严重。到目前为止，我没有见过关于两者的严重程度的比较，不过在我来看，DOM型XSS的危害要比反射型XSS更大一些。

DOM型XSS与反射型XSS

让我们从Altoro Mutual网站开始吧。您可以在搜索栏中键入一个脚本，例如在起始和结束<script>标签中插入alert(“hello”) ，如下所示：

当您点击回车键时，该脚本将会执行（反射型XSS），这时会看到：

但是，您也可能看不到弹出的内容。例如，如果在公司环境中，那么公司代理可能会阻止该脚本的运行。如果您使用的是Chrome，则可能会发现Chrome会将其屏蔽（请参见下面的截图）。这两种情况都有相应的解决办法，但如果该漏洞只在特殊情况下才有效的话，这个漏洞的严重性就会明显降低。

现在让我们尝试一下OWASP Juice Shop中的XSS漏洞。在搜索栏中输入脚本：

按回车键后，就会看（DOM型XSS）：

在我的实验过程中，公司代理和Chrome都没有阻止它，说明这个漏洞非常严重。 

我们看到，搜索栏中输入的脚本作为html的一部分反射了回来。
现在，看看从Juice Shop那里截取的数据：

从这里可以看到，输入的内容并没有反射回来。
现在，我们进一步深入考察。如果打开浏览器开发工具，会发现搜索值是通过客户端JavaScript放入html中的。Juice Shop网站默认的html代码里面有一个输入表单，其中包含：

ng-model是AngularJS的功能。默认情况下，AngularJS会对相关的内容进行转义来防止XSS，除非您以一种令人无语的方式来编写JavaScript代码，就像Juice Shop故意为之的那样：

trustAsHtml是一种Angular方法，它不会进行默认的转义处理。
企业代理和浏览器（Firefox除外）可以通过检查发送的字符串是否包含脚本并查看是否返回完全相同的字符串来轻松阻止反射型XSS，以此阻止黑客的入侵。
但是这种保护措施对DOM型XSS来说不起作用，因为这种攻击完全发生在浏览器中，所以公司代理也爱莫能助。同时，与反射型XSS相比，浏览器在阻止DOM型XSS方面要困难得多。

然后，创建受害者用户的帐户：

接下来，用受害者账户登录：

一切都很正常，直到受害者发现OWASP的Juice Shop网站正在赠送免费果汁，那还等什么，赶紧去抢啊（对于我们的临时部署来说，该链接为：https://frozen-crag-69213.herokuapp.com/freejuice):

点击链接后，将触发DOM型XSS漏洞。对于非技术用户来说，可能不知道当前已经执行了一个来自恶意站点的脚本。事实上，在这种情况下，脚本已经将受害者的cookie取出并发送到恶意网站。该恶意网站有一个“/recorddata”端点，用于将cookie记录到一个临时文件中（更正规的做法是使用数据库）。

我们的恶意服务器还有一个“/dumpdata”端点，用于显示所有捕获的cookie。

Cookie内部有一个JWT。现在，让我们将该JWT复制到剪贴板中：

现在，导航至jwt.io网站，我们可以将令牌粘贴到这里，并对其进行解码：

天哪，用户名和密码都在Cookie中。但这里并非真正的密码，那咋整？请教谷歌大神：

点击第一个链接，我们发现它是密码的MD5哈希值。真正的密码显示在下面链接中：

总结

我发现，与给他们讲解无聊的编码准则相比，开发人员更乐于理解安全漏洞并考察这些漏洞的实际利用场景。一旦他们意识到了这些安全问题，他们就能找到正确的编码方法。要知道，开发人员非常善于利用Google来理解他们面临的问题，并找到相应的解决方案。