web渗透—xss之基于DOM漏洞

这个漏洞往往存在于客户端脚本，如果一个Javascript脚本访问需要参数的URL，且需要将该信息用于写入自己的页面，且信息未被编码，那么就有可能存在这个漏洞。

(一)DOM—based XSS漏洞的产生

DOM—based XSS漏洞是基于文档对象模型Document Objeet Model，DOM)的一种漏洞。DOM是一个与平台、编程语言无关的接口，它允许程序或脚本动态地访问和更新文档内容、结构和样式，处理后的结果能够成为显示页面的一部分。DOM中有很多对象，其中一些是用户可以操纵的，如uRI，location，refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容，它不依赖于提交数据到服务器端，而从客户端获得DOM中的数据在本地执行，如果DOM中的数据没有经过严格确认，就会产生DOM—based XSS漏洞。

(二)DOM—based XSS攻击原理

DOM—based XSS攻击源于DOM相关的属性和方法，被插入用于XSS攻击的脚本。一个典型的例子如下所述。

H TTP请求http：／／www．DBXSSed．site／welcome．html?name=zhangsan使用以下的脚本打印出登录用户zhangsan的名字，即

<SCRIPT>var pos=docmnent．URL．indexOf(”name=”)+5;document．write(document．URL．substring(pos，document．URL．1ength))；

< /SCRIPT>

如果这个脚本用于请求http：／／www．DBXSSed．site／wPJconle．html?name=<script>alert(‘‘XSS”)<／script>时，就

导致XSS攻击的发生。

当用户点击这个链接，服务器返回包含上面脚本的HTML静态文本，用户浏览器把HTML文本解析成DOM，DOM中的document对象URL属性的值就是当前页而的URL。在脚本被解析时，这个URL属性值的一部分被写入HTML文本，而这部分HTML文本却是JavaScript脚本，这使得<script>alert(“XSS”)<／script>成为页面最终显示的HTML文本，从而导致DOM—base XSS攻击发生。

DOM—based XSS攻击过程如图l所示。

注意（5）黑客提供的URL被页面的JAVASCRIPT使用，生成攻击载荷。

下面是一篇比较易懂的文章，觉得不错，读后对dom xss有比较清晰的认识：

用户可以从一个表单页提交数据，数据提交到服务期端后进行html编码后保存到数据库，然后有个修改这个提交信息的页面，会把信息从数据库里查询出来，填充到INPUT控件的VALUE属性里，来达到一个展示现有数据的效果。这里的数据在输出到value之前经过html编码的，所以输出到value里没有跨站的问题，但是这里程序为了实现一个其他功能，加了段js脚本，脚本取得前面提到的INPUT控件的VALUE，进行了一系列的动作和条件判断后，符合条件的话就把这个VALUE值放到一个DIV的INNERHTML里，这一放就放出了一个跨站问题来。可能你比较奇怪，不是VALUE里的值被HTML编码过了么，为什么这里还有问题呢，其实如果源代码是VALUE="<a>"，虽然经过HTML编码，但是用脚本通过DOM的方式来取得VALUE的值的时候，又会被解码。如果看我语言描述不太明白的话，下面例子的php语法简单演示：

<?php

// 从数据库取得name

$name = htmlentities(get_name_from_db());

?>

name:

<input id="tb1" type="text" value="<?php echo $name;?>" />

<div id="pnl1"></div>

<script type="text/javascript">

<!–

var tb1 = document.getElementById("tb1");

var pnl1 = document.getElementById("pnl1");

if (…/*一些判断*/…) {

pnl1.innerHTML = tb1.value; // xss

}

//–>

</script>

假设我输入一个<button>，这个修改页面的源代码应该是这样，页面里就会冒出个没有字的按钮：

name:

<input id="tb1" type="text" value="<button>" />

<div id="pnl1"></div>

<script type="text/javascript">

<!–

var tb1 = document.getElementById("tb1");

var pnl1 = document.getElementById("pnl1");

if (…/*一些判断*/…) {

pnl1.innerHTML = tb1.value; // xss

}

//–>

</script>

于是你很容易就会想到写入这样一句：<script>alert(document.cookie);</script>，结果呢？并没有一个熟悉的对话框弹出来，INNERHTML属性里写入<script>块是不会被执行的，所以呢我们要用事件来执行我们的代码：

<img src="http://image2.sina.com.cn/home/images/sina_logo2.gif" width="0" height="0" border="0" onload="javascript:alert(document.cookie);">

如下：

这个函数是不安全的，如果参数带有用户输入，就可能导致执行JS代码：

function HTMLDecode(strEncodeHTML)

{

var div = document.createElement('div');

div.innerHTML = strEncodeHTML;

return div.innerText;

}

HTMLDecode("<img src=1 onerror=alert(1) />");

有人以为，这个没有被appendChild到dom树的元素，应该不会执行。

例如，假设应用程序返回的错误页面包含以下脚本：

这段脚本解析 URL，提取出message参数的值，并把这个值写入页面的HTML源代码中。如果按开发者预想的方式调用，它可以和前面的示例中一样，用于创建错误消息。但是，如果攻击者设计出一个URL，并以JavaScript代码作为message参数，那么这段代码将被动态写入页面中，并像服务器返回代码一样得以执行。

在这个示例中，前面示例中利用反射型XSS漏洞的相同URL也可用于生成一个对话框：

https://wahh-app.com/error.php?message=<script>alert('xss'）;</script>

（三）XSS解决方案

常用的防止XSS技术包括：

（1）与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。

（2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。

（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。

（4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。

（5）在发布应用程序之前测试所有已知的威胁。