浅析XSS(Cross Site Script)漏洞原理

最近一些人频频在博客里炫耀说黑了某某门户网站,发现了某某大站的漏洞,竟然还要收取发现漏洞的费用,仔细瞧了一瞧,全是一片噼里啪啦alert消息框的截图,只是简单的触发了XSS,心痒难耐,于是写了这篇拙文道出我对跨站脚本漏洞原理的一些理解。

    如果你还不知道什么是XSS,我来帮助解释一下,XSS的全称是Cross Site Scripting,意思是跨站脚本.这第一个单词是Cross,为什么缩写成X呢?因为CSS是层叠样式表的缩写(Cascading Style Sheets)的缩写,同时Cross发音和X相似,为了避免混淆用X来代替,缩写成XSS。其实我觉得叫XSS挺合适的,因为现在流行AJAX嘛,新的跨站脚本攻击技术很多都是和XMLHTTP控件无间配合,嘿嘿,这个是题外话,我们只讲原理,下面我就分两个部分分析XSS原理:

    一、XSS的触发条件

    了解XSS的触发条件就先得从HTML(超文本标记语言)开始,我们浏览的网页全部都是基于超文本标记语言创建的,如显示一个超链接:

    <A HREF="http://safe.it168.com">IT168安全频道</A>


    而XSS的原理也就是往HTML中注入脚本,HTML指定了脚本标记<script></script>.在没有过滤字符的情况下,只需要保持完整无错的脚本标记即可触发XSS,假如我们在某个资料表单提交内容,表单提交内容就是某个标记属性所赋的值,我们可以构造如下值来闭和标记来构造完整无错的脚本标记,

    "><script>alert('XSS');</script><"

    结果形成了<A HREF=""><script>alert('XSS');</script> <"">茄子宝的博客在这里</A>这样一个标记,:)这里和SQL注入很象!

    测试闭和表单赋值所在的标记,形成完整无错的脚本标记可触发XSS,但是没有脚本标记怎么触发XSS呢?呵呵,我们只好利用其他标记了,假如要在网页里显示一张图片,那么就要使用一个<img>标记,示例如下:

    <img src=" http://safe.it168.com /xss.gif">

    img标记并不是真正地把图片给加入到Html文档把两者合二为一,而是通过src属性赋值。那么浏览器的任务就是解释这个img标记,访问src属性所赋的值中的URL地址并输出图片。问题来了!浏览器会不会检测src属性所赋的值呢?答案是否!那么我们就可以在这里大做文章了,接触过javascript的同志应该知道,javascript有一个URL伪协议,可以使用“javascript:”这种协议说明符加上任意的javascript代码,当浏览器装载这样的URL时,便会执行其中的代码.于是我们就得出了一个经典的XSS示例:

    <img src="javascript:alert('XSS');"> 如图一

    当然并不是所有标记的属性都能用,细心的你应该发现标记的属性在访问文件才触发的XSS,这里我就不再深入,因为离开标记的属性还有事件能帮助我们触发XSS.那什么是事件呢?只有达到某个条件才会引发事件,正巧img标记有一个可以利用的onerror()事件,当img标记内含有一个onerror()事件而正好图片没有正常输出便会触发这个事件,而事件中可以加入任意的脚本代码,其中的代码也会执行.现在我们又得到了另外一个经典的XSS示例:

<img src=" http://xss.jpg" onerror=alert('XSS')>如图二

    综合这一部分,我们知道XSS的触发条件包括:完整无错的脚本标记,访问文件的标记属性和触发事件。

二、XSS转码引发的过滤问题

    有攻就有防,网站程序员肯定不会放任大家利用XSS,所以他们常会过滤类似javascript的关键字符,让大家构造不了自己的XSS,我这里就捡两个被忽略惯了的字符来说,它们是"&"和"\".首先来说说"&"字符,玩过SQL注入的都知道,注入的语句可以转成16进制再赋给一个变量运行,XSS的转码和这个还真有异曲同工之妙,原因是我们的IE浏览器默认采用的是UNICODE编码,HTML编码可以用&#ASCII方式来写,这种XSS转码支持10进制和16进制,SQL注入转码是将16进制字符串赋给一个变量,而XSS转码则是针对属性所赋的值,下面我就拿<img src="javascript:alert('XSS');">示例:

    <img src="&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116&#58&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41&#59"> //10进制转码 如图三

    <img src="&#x6a&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3a&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29&#x3b"> //16进制转码。

    这个&#分隔符还可以继续加0变成“&#0106” ,“&#00106” ,“&#000106” ,“&#0000106”等形式。

    而这个"\"字符却暴露了一个严重的XSS 0DAY漏洞,这个漏洞和CSS(Cascading Style Sheets)层叠样式表有很大的关联,下面我就来看看这个漏洞,先举个javascript的eval 函数的例子,官方是这样定义这个函数:

    eval(codeString),必选项 codestring 参数是包含有效 JScript 代码的字符串值。这个字符串将由 JScript 分析器进行分析和执行。

    我们的JavaScript中的"\"字符是转义字符,所以可以使用"\"连接16进制字符串运行代码

    <SCRIPT LANGUAGE="JavaScript">
eval("\x6a\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3a\x61\x6c\x65\x72\x74\x28\x22\x58\x53\x53\x22\x29")
</SCRIPT>

恐怖的是样式表也支持分析和解释"\"连接的16进制字符串形式,浏览器能正常解释。下面我们来做个实验:

    写一个指定某图片为网页背景的CSS标记:

    <html>
    <body>
    <style>
    BODY { background: url(http://127.0.0.1/xss.gif) }
    </style>
    <body>
    <html>

    保存为HTM,浏览器打开显示正常。

    转换background属性值为"\"连接的16进制字符串形式,浏览器打开同样显示正常。

    <html>
    <body>
    <style>
    BODY { background: \75\72\6c\28\68\74\74\70\3a\2f\2f\31\32\37\2e\30\2e\30\2e\31\2f\78\73\73\2e\67\69\66\29 }
    </style>
    <body>
    <html>

    在文章第一部分我已经说过XSS的触发条件包括访问文件的标记属性,因此我们不难构造出

    <img STYLE="background-image: url(javascript:alert('XSS'))">

    这样的XSS语句。有了实验的结果,我们又能对CSS样式表的标记进行XSS转码,浏览器将帮我们解释标记内容,XSS语句示例:

    <img STYLE="background-image: \75\72\6c\28\6a\61\76\61\73\63\72\69\70\74\3a\61\6c\65\72\74\28\27\58\53\53\27\29\29"> 看图四

    编者语:XSS攻击以及的可怕性及灵活性深受黑客的喜爱。争对XSS攻击,编者给普通浏览网页用户及WEB应用开发者给出以下的安全建议:

    web用户

    1.在电子邮件或者即时通讯软件中点击链接时需要格外小心:留心可疑的过长链接,尤其是它们看上去包含了HTML代码。如果对其产生怀疑,可以在浏览器地址栏中手工输入域名,而后通过该页面中的链接浏览你所要的信息。

    2.对于XSS漏洞,没有哪种web浏览器具有明显的安全优势。也就是Firefox也同样不安全。为了获得更多的安全性,可以安装一些浏览器插件:比如Firefox的NoScript或者Netcraft工具条。

    3.世界上没有“100%的有效”。尽量避免访问有问题的站点:比如提供hack信息和工具、破解软件、成人照片的网站。这些类型的网站会利用浏览器漏洞并危害操作系统

    web应用开发者

    1.对于开发者,首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。这些提交内容包括URL、查询关键字、http头、post数据等。只接受在你所规定长度范围内、采用适当格式、你所希望的字符。阻塞、过滤或者忽略其它的任何东西。

    2.保护所有敏感的功能,以防被bots自动化或者被第三方网站所执行。实现session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查。

    3.如果你的web应用必须支持用户提供的HTML,那么应用的安全性将受到灾难性的下滑。但是你还是可以做一些事来保护web站点:确认你接收的HTML内容被妥善地格式化,仅包含最小化的、安全的tag(绝对没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript)。为了更多的安全,请使用httpOnly的cookie。

转载自:http://publish.it168.com/2007/0704/20070704004201.shtml

posted @ 2011-09-02 00:59  天平盛世  阅读(493)  评论(0编辑  收藏  举报