这个漏洞往往存在于客户端脚本，如果一个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 = ElementById("tb1");
var pnl1 = ElementById("pnl1");
if (…/*一些判断*/…) {
pnl1.innerHTML = tb1.value; // xss
}
//–>
</script>
假设我输入一个<button>，这个修改页面的源代码应该是这样，页面里就会冒出个没有字的按钮：
name:
<input id="tb1" type="text" value="<button>" />
js脚本开发<div id="pnl1"></div>
<script type="text/javascript">
<!–
var tb1 = ElementById("tb1");
var pnl1 = ElementById("pnl1");
if (…/*一些判断*/…) {
pnl1.innerHTML = tb1.value; // xss
}
//–>
</script>
于是你很容易就会想到写入这样一句：<script>kie);</script>，结果呢？并
没有一个熟悉的对话框弹出来，INNERHTML属性里写入<script>块是不会被执行的，所以呢我们要
用事件来执行我们的代码：
<img src="image2.sina/home/images/sina_logo2.gif" width="0" height="0" border="0" onload="javascript:kie);">
写完了回头想想，这个例子被我添油加醋后显得不那么合常理了，不过不影响我要表达的意思，所
以合理性大家就不要追究了。
-------------------------------------------------------------------------------------------
luoluo有写过一篇老文章，讲htmldecode dom时的xss，可以参考下，到此dom xss就很容易理解了~
如下：
这个函数是不安全的，如果参数带有用户输入，就可能导致执行JS代码：
function HTMLDecode(strEncodeHTML)
{
var div = ateElement('div');
div.innerHTML = strEncodeHTML;
return div.innerText;
}
HTMLDecode("<img src=1 onerror=alert(1) />");
有人很傻很天真的以为，这个没有被appendChild到dom树的元素，应该不会执行。
例如，假设应用程序返回的错误页面包含以下脚本：
这段脚本解析 URL，提取出message参数的值，并把这个值写入页面的HTML源代码中。如果按开发者预想的方式调用，它可以和前面的示例中一样，用于创建错误消息。但是，如果攻击者设计出一个 URL，并以JavaScript代码作为message参数，那么这段代码将被动态写入页面中，并像服务器返回代码一样得以执行。在这个示例中，前面示例中利用反射型XSS漏洞的相同URL也可用于生成一个对话框：wahh-app/error.php?message=<script>alert('xss'）;</script>
（三）XSS解决方
案
常用的防止XSS技术包括：
（1）与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
（2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
（4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
（5）在发布应用程序之前测试所有已知的威胁。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。