基于 DOM 的第三类跨站脚本 XSS 已翻译 100%

wyzc小胖胖 投递于 2013/02/18 16:37 (共 18 段, 翻译完成于 02-19)
阅读 19566
收藏 18
xss
4
加载中

摘要

我们都听说过跨站脚本(xss),对吗?它利用恶意的数据(通常是使用javascript代码填充到html中)嵌入到你的应用程序的HTML文本中,然后执行注入的javascript代码。好吧,错了。还有一种和这个描述不太相符的XSS,至少在一些基本性质上不一样。上面描述的XSS攻击要么是“非持久”/“反射”(即恶意数据嵌入到页面后会紧跟请求立刻返回到浏览器)要么是“持久化”/“存储型”(在这种情况下恶意数据一段时间后也能返回)。但是还存在第三种XSS攻击-这种类型的攻击不依赖于起初发送到服务端的恶意数据!虽然这似乎与定义和常识有些矛盾,事实上,对于这类攻击有两个很好的描述例子。我们讨论的这个技术被称为“DOM Based XSS(基于dom的xss)”。对于攻击来说没什么新颖的,当然,在这篇文章中这个创新属于一个不同的“味道”,这个“味道”还是蛮有趣和重要的。

缪斯的情人
缪斯的情人
翻译于 2013/02/18 20:45
1

应用程序开发者和用户需要了解基于DOM的XSS,由于它代表了web应用程序的一种威胁,比标准的XSS有了不同的先决条件。同样地,互联网上很多web应用程序易受基于DOM的XSS攻击,但是当测试(标准的)XSS时,它却被标明为“非脆弱的”。开发人员和网站维护人员(或者审计员)需要熟悉相关技术来检测基于DOM的xss漏洞,以及使用相关技术来防护该漏洞的攻击,这些和适用的标准xss有些不同。

缪斯的情人
缪斯的情人
翻译于 2013/02/18 21:01
1

介绍

假定读者具有xss的一些基础知识 ([1], [2], [3], [4], [8])。XSS典型分类是“非持久型”和“持久型”([3], “反射型” 和 “存储型” 相应定义在 [4])。“非持久型”意味着恶意(javascript)程序脚本主要是在受害者请求HTTP后得到一个即刻的响应时执行。“持久型”意味着恶意程序脚本被存在系统中,或许以后在提供给受害者的一个易受攻击的HTML页面里嵌入攻击代码。正如前面摘要里提到的,这个分类假设XSS基本属性拥有恶意程序脚本从浏览器转移到服务器并且在相同的浏览器返回(在非持久型xss)或者任何(持久型xss)浏览器。这篇文章指出这是一个误解,虽然在自然情况下没有这么多反例,少量存在的XSS攻击不依赖于嵌入的服务器响应恶意程序脚本,最重要的是因为它影响检测和防护的方法。这在文档里都有讨论。

缪斯的情人
缪斯的情人
翻译于 2013/02/18 21:40
1

例子和讨论

在描述基本方案前,先强调下这里一些技术概论已经得到公众的证明 (比如 [5], [6][7]),同样地,下面的也不是一些新技术(尽管可能有些陌生技术)。

前提是易受攻击的网站有一个HTML页面采用不安全的方式从document.locationdocument.URL 或 document.referrer获取数据(或者任何其他攻击者可以修改的对象).

缪斯的情人
缪斯的情人
翻译于 2013/02/18 21:54
1
注意这些读者不熟悉的javascript对象:当javascript在浏览器执行时,浏览器提供给javascript代码几个DOM对象。文档对象首先在这些对象之中,并且它代表着大多数浏览器呈现的页面的属性。这个文档对象包含很多子对象,例如location,URL和referrer。这些对象根据浏览器的显示填充浏览器。因此, document.URL 和 document.location是由页面的URL按照浏览器的解析填充的。注意这些对象不是提取自HTML的body-它们不会出现在数据页面。文档对象包含一个body对象,它代表对于HTML的解析。
缪斯的情人
缪斯的情人
翻译于 2013/02/18 22:13
1

你常常会发现在一个应用程序的HTML页面里包含解析URL(通过访问document.URL 或者 document.location)和执行一些客户端逻辑的javascript代码,下面的例子就是对这样一个逻辑的说明。

[2]有类似的例子(本质上和场景[7]讲到的一样),考虑到例如下面的HTML页面(这个内容来自于http://www.vulnerable.site/welcome.html):

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>
通常这个页面作为用户欢迎页面, 例如:

  http://www.vulnerable.site/welcome.html?name=Joe

然而,如下的一个请求:

  http://www.vulnerable.site/welcome.html?name=
  <script>alert(document.cookie)</script>

将产生xss条件。让我们看看为什么:受害者的浏览器接收到这个链接,发送HTTP请求到www.vulnerable.site并且接受到上面的HTML页。受害者的浏览器开始解析这个HTML为DOM,DOM包含一个对象叫document,document里面有个URL属性,这个属性里填充着当前页面的URL。当解析器到达javascript代码,它会执行它并且修改你的HTML页面。倘若代码中引用了document.URL,那么,这部分字符串将会在解析时嵌入到HTML中,然后立即解析,同时,javascript代码会找到(alert(…))并且在同一个页面执行它,这就产生了xss的条件。

缪斯的情人
缪斯的情人
翻译于 2013/02/19 10:10
1

注意:

1. 恶意程序脚本在任何时候不会嵌入到处于自然状态下的HTML页面(这和其他种类的xss不太一样)。

2.这个攻击只有在浏览器没有修改URL字符时起作用。 当url不是直接在地址栏输入,Mozilla.会自动转换在document.URL中字符<和>(转化为%3C 和 %3E),因此在就不会受到上面示例那样的攻击了,在IE6下没有转换<和>,因此他很容易受到攻击。

当然,直接嵌入到HTML只是攻击的一个挂载点,有很多脚本不需要依赖<和>漏洞,因此Mozilla通常也是无法阻止这些攻击的。

缪斯的情人
缪斯的情人
翻译于 2013/02/19 10:22
1

绕过标准检测和防护的技术

在上面的例子中,可能仍然存在争论,恶意脚本没有到达服务器(在HTTP请求的查询部分),也就能像其他xss攻击一样阻止它了。但是我们还是能“照顾”好它免受打击的,看下面的攻击:

http://www.vulnerable.site/welcome.html#name=<script>alert(document.cookie)<script>

注意文件名后面的数字符号(#),它告诉浏览器所有它后面的东西都是个片段,也就是不作为查询的一部分。IE(6.0)和Mozilla不会把这个片段发送到服务器,因此服务端将看到同样的http://www.vulnerable.site/welcome.html,这样这个恶意脚本就不会被服务端看到。我们了解到这个逃避技术主要是利用浏览器不向服务器发送恶意脚本。

缪斯的情人
缪斯的情人
翻译于 2013/02/19 10:36
1

有时,完全隐藏恶意脚本很难做到:在[5] 和 [6],username是恶意脚本的一部分,URL看起来像http://username@host/,浏览器在这样的情况下,发送一个包含username的授权头,因此,恶意脚本就到达了服务器(Base64 编码-IDS/IPS需要解编码这个数据后才能观察到攻击)。当然,以防xss攻击条件的产生,服务器可以不请求嵌入这段脚本。

明显地,在恶意脚本可以完全隐藏的情况下,在线检查(IDS)和防护(IPS,web应用程序防火墙)产品就无法完全阻挡攻击了,假设易受攻击的脚本确实可以通过一个已知的location调用。即使恶意脚本被发送到服务器,在很多情况下都可以通过巧妙地伪装躲避检测,如,假设有个受保护的特殊参数(像上面的name参数),那么做一个细微的变化都有可能引起成功的攻击:

  http://www.vulnerable.site/welcome.html?notname=<script>(document.cookie)</script>

一个更严格的安全策略是需要发送时带有name参数(避免上面使用name和#的小技巧)。我们仍可以使用下面发送:

  http://www.vulnerable.site/welcome.html?notname=
  <script>alert(document.cookie)<script>&name=Joe

如果策略约束了参数名称(如,foobar),那么下面攻击仍可以成功:

  http://www.vulnerable.site/welcome.html?foobar=
  name=<script>alert(document.cookie)<script>&name=Joe

注意foobar参数必须放在首位,恶意脚本包含在它的值里面。

缪斯的情人
缪斯的情人
翻译于 2013/02/19 11:30
1

在章节[7]中更好的从攻击者的角度做了讲述,由于document.location被嵌入HTML页面(javascript代码没有过滤特殊参数),所以攻击者可以完全隐藏恶意脚本如下:

  /attachment.cgi?id=&action=
  foobar#<script>alert(document.cookie)</script>

即使恶意脚本被服务器检查,防护也只限于保证它的请求中没有拒绝的信息,或者响应里没有被错误文本替换的。重新看一下[5] 和 [6]章,如果授权头部被一个中间保护系统移除了,只要原来的页面返回了那就没啥影响。同样滴,任何企图在服务器清理这些数据的,要么移除攻击字符,要么对他们进行编码,对于这种攻击都是无效的。

缪斯的情人
缪斯的情人
翻译于 2013/02/19 11:43
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(16)

bbzhang
bbzhang
翻译的好!~很受益!另外,发现了一个小问题:

在上面的例子中,可能仍然存在争论,恶意脚本没有到达服务器(在HTTP请求的查询部分),也就能像其他xss攻击一样阻止它了。但是我们还是能“照顾”好它免受打击的,看下面的攻击:

原文是:the payload did arrive to the server,恶意脚本到达了服务器。
缪斯的情人
缪斯的情人

引用来自“小胖胖_要减肥”的评论

引用来自“缪斯的情人”的评论

引用来自“红薯”的评论

@缪斯的情人 你太强了!

介文章太老了,DOM攻击都流行开了

真的很强 那个2012年猥琐流的比较新的 我要自己看看有什么号文章先http://blog.whitehatsec.com/top-ten-web-hacking-techniques-of-2012/

这个网站不粗,白帽子
wyzc小胖胖
wyzc小胖胖

引用来自“缪斯的情人”的评论

引用来自“红薯”的评论

@缪斯的情人 你太强了!

介文章太老了,DOM攻击都流行开了

真的很强 那个2012年猥琐流的比较新的 我要自己看看有什么号文章先http://blog.whitehatsec.com/top-ten-web-hacking-techniques-of-2012/
缪斯的情人
缪斯的情人

引用来自“红薯”的评论

@缪斯的情人 你太强了!

介文章太老了,DOM攻击都流行开了
红薯
红薯
@缪斯的情人 你太强了!
蟋蟀哥哥
蟋蟀哥哥
尼玛太长了
缪斯的情人
缪斯的情人

引用来自“小胖胖_要减肥”的评论

引用来自“缪斯的情人”的评论

引用来自“小胖胖_要减肥”的评论

引用来自“缪斯的情人”的评论

@蟋蟀哥哥 你不翻译下?

他小学都没毕业你让他翻译? 你找他搞基倒可以 哈哈 蟋蟀给点好玩的东西搞搞吧 你好久不发东西了

不会吧,莫吓我,这文章有点长!要不你配合下

我看了很多看的太生涩啊,不想误导别人,而且这篇作为dom xss普及篇不错

最后两段总可以翻译吧
wyzc小胖胖
wyzc小胖胖

引用来自“缪斯的情人”的评论

引用来自“小胖胖_要减肥”的评论

引用来自“缪斯的情人”的评论

@蟋蟀哥哥 你不翻译下?

他小学都没毕业你让他翻译? 你找他搞基倒可以 哈哈 蟋蟀给点好玩的东西搞搞吧 你好久不发东西了

不会吧,莫吓我,这文章有点长!要不你配合下

我看了很多看的太生涩啊,不想误导别人,而且这篇作为dom xss普及篇不错
缪斯的情人
缪斯的情人

引用来自“小胖胖_要减肥”的评论

引用来自“缪斯的情人”的评论

@蟋蟀哥哥 你不翻译下?

他小学都没毕业你让他翻译? 你找他搞基倒可以 哈哈 蟋蟀给点好玩的东西搞搞吧 你好久不发东西了

不会吧,莫吓我,这文章有点长!要不你配合下
wyzc小胖胖
wyzc小胖胖

引用来自“缪斯的情人”的评论

@蟋蟀哥哥 你不翻译下?

他小学都没毕业你让他翻译? 你找他搞基倒可以 哈哈 蟋蟀给点好玩的东西搞搞吧 你好久不发东西了
返回顶部
顶部