易栈网-膘叔

本来不想转这个的，因为原文好象不全，但我试着将原文最后一句去掉，好象也能读的通，就先转上来看看了。。。

原文：http://netsecurity.51cto.com/art/200902/112190.htm

IE有一个特性，那就是在将一个文件展示给用户之前会首先检查文件的类型，这乍看起来并没什么问题，但实际上这是相当危险的，因为这会允许IE执行 图片中的代码，即嵌入在一个图像中的JavaScript代码。引入MIME sniffing功能的初衷是用来弥补Web服务器响应一个图像请求时有可能返回错误的内容类型信息这一缺陷。

但是事不遂人愿，心怀不轨的人可以轻易滥用这一特性，如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的HTML和JavaScript代码。本文将深入考察该问题，并为用户和网站开发人员介绍如何降低此问题带来的风险。

一、危险的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 代码

原文：http://netsecurity.51cto.com/art/200902/111415.htm
作者：康凯

由于51CTO上面的文章排版很乱，因此我在复制回来后，重新排版。。。应该会比原文好看一点吧？原文里很多单引号都是用了中文字符的单引号了。已改回来。

原文如下：

跨站脚本的名称源自于这样一个事实，即一个Web 站点(或者人)可以把他们的选择的代码越过安全边界线注射到另一个不同的、有漏洞的Web 站点中。当这些注入的代码作为目标站点的代码在受害者的浏览器中执行时，攻击者就能窃取相应的敏感数据，并强迫用户做一些用户非本意的事情。

在本文中，我们论述浏览器方面的安全措施，以及如何利用跨站脚本（XSS）这种常见的技术来规避浏览器的安全措施。在正式讨论跨站脚本攻击之前，我们必须首先要对现有的安全措施有所了解，所以本文将详细介绍当前Web应用所采取的安全措施，如同源策略、cookie安全模型以及Flash的安全模型。

一、Web安全模型

尽管浏览器的安全措施多种多样，但是要想黑掉一个Web应用，只要在浏览器的多种安全措施中找到某种措施的一个漏洞或者绕过一种安全措施的方法即可。浏览器的各种保安措施之间都试图保持相互独立，但是攻击者只要能在出错的地方注入少许JavaScript，所有安全控制几乎全部瓦解——最后还起作用的就是最弱的安全防线：同源策略。同源策略管辖着所有保安措施，然而，由于浏览器及其插件，诸如Acrobat Reader、Flash 和Outlook Express漏洞频出，致使同源策略也频频告破。在本文里，我们主要讨论浏览器的三个安全模型：
1.同源策略
2.cookies安全模型
3.Flash安全模型

此外，我们还会介绍如何利用JavaScript代码削弱这些安全模型的方法。

二、同源策略

　　同源策略又名同域策略是浏览器中的主要安全措施。这里的“源”指的是主机名、协议和端口号的组合；我们可以把一个“源”看作是某个web页面或浏览器所浏览的信息的创建者。同源策略，简单地说就是要求动态内容（例如，JavaScript或者VBScript）只能阅读与之同源的那些HTTP应答和cookies，而不能阅读来自不同源的内容。更为有趣的是，同源策略对写操作没有任何限制。因而，一个web站点可以向任何其他的Web站点发送（或写入）HTTP请求，尽管为了防止跨站请求可能会对发送这些请求有关的cookies和头部有所限制。

　　解释同源策略的最好的方法是实例说明。假定我们在网页http://foo.com/bar/baz.html中放上了JavaScript代码。那么，这些JavaScript可以读/写一些页面，但是却不能读/写其他页面。下表说明了来自http://foo.com/bar/baz.html的JavaScript可以访问哪些URL。

　　上表说明了当http://foo.com/bar/baz.html试图加载某些URL时同源策略的工作情况。下面我们介绍同源策略的例外。通过在被请求的页面中对JavaScript的变量document.domain进行相应设置，可以使浏览器有限度地违反同源策略，即，如果http://www.foo.com/bar/baz.html页面中含有下列内容：

　　那么任何http://xyz.foo.com/anywhere.html页面内的脚本都可以向http://www.foo.com/bar/baz.html发送HTTP请求，并可以读取其内容。在此种情况下，如果攻击者能够向http://xyz.foo.com/anywhere.html中注入HTML或JavaScript的话，那么他同时也能在http://www.foo.com/bar/baz.html中注入JavaScript代码。
为此，攻击者需要首先在http://xyz.foo.com/anywhere.html（其document.domain设为foo.com）中注入HTML和JavaScript，并向http://www.foo.com/bar/baz.html（其document.domain也设为foo.com）中载入一个iframe，然后就可以通过JavaScript来访问该iframe的内容了。例如，http://xyz.foo.com/anywhere.html中的下列代码将在www.foo.com域中执行一个JavaScript的alert（）函数：

　　这样，document.domain将允许攻击者跨域活动（域际旅行）。注意，你不能在document.domain变量中放入任何域名，相反，只能在document.domain变量中放置“源”页面即所在页面的域名的上级域名，如www.foo.com的上级域名是foo.com 。
在 Firefox浏览器中，攻击者可以利用__defineGetter__()来操纵document.domain，命令 document.domain返回攻击者所选的任意字符串。这个不会损害浏览器的同源策略，因为它只对JavaScript引擎有影响，而不会影响底层的文档对象模型(DOM)，然而这对于依靠document.domain在后台进行跨域请求的JavaScript应用程序却是有影响的。例如，假如一个后台请求http://somesite.com/GetInformation?callback=callbackFunction的应答的HTTP体如下所示：

　　通过诱骗受害者访问（攻击者的）包含下列脚本的页面，攻击者就可以可以获得保密资料：

　　这段HTML代码利用__defineGetter__()对document.domain进行了设置，并且建立了一个针对http://somesite.com/GetInformation?callback=callbackFunction的跨域请求。最后，它会在1.5秒——对于浏览器建立到达somesite.com的请求来说，这个时间已经够宽裕了——之后调用 sendInfoToEvilSite(callbackFunction())。因此，我们不应扩展document.domain来用作它用。
如果同源策略失守，后果如何？同源策略使得一个“邪恶的”Web 站点无法访问其它的Web 站点，然而，一旦同源策略被攻破，后果将会如何？攻击者将可以作哪些事情？下面让我们考察一个假想的例子。
假如一位攻击者在http://www.evil.com/index.html建立了一个页面，该页面可以阅读来自其它域的HTTP应答，例如来自一个webmail应用程序的应答等，并且攻击者可以诱骗webmail用户访问http://www.evil.com/index.html。那么，攻击者将能阅读受骗用户的通信录。 为此，攻击者可以在http://www.evil.com/index.html中放入

下列JavaScript代码：

　　第一步使用了一个名为WebmailIframe的iframe来装载http://webmail.foo.com/ViewContacts，它是webmail应用程序中的一个调用，用以收集用户的联系人名单。

第二步是等待1秒钟，然后执行JavaScript函数doEvil（）。这个延迟能确保联系人名单被装载到iframe中。确认联系人名单已经被装载到iframe之后，doEvil（）尝试访问在步骤三中的iframe得到的数据。如果同源策略被攻陷或不存在的话，攻击者就已经在变量 victimsContactList得到了受害者的联系人名单。攻击者可以利用JavaScript和该页面的表单将联系人名单发送至evil.com的服务器。

如果攻击者利用跨站请求伪造（CSRF）技术以受害者的名义向所有联系人发送电子邮件的话，情况会变得更糟：这些联系人将收到一封貌似来自朋友的电子邮件，并且在邮件中邀请他们点击http://www.evil.com/index.html。

注意，如果同源策略失守的话，那么任何Web应用都容易受到攻击，而不仅仅是Webmail应用。 这时Web将没有安全可言，目前的许多安全研究的焦点都集中在攻破同源策略上面。 过不了多久，您就会有惊奇的发现。

三、Cookie安全模型

HTTP是一种无状态协议，这意味着一个HTTP请求/应答对跟另一个HTTP请求/应答对毫不相干。随着HTTP的发展，开发人员希望能够维护所有请求/应答的某些数据，这样他们就能够建立更丰富多彩的Web应用。为此，RFC2109建立了一种标准，每个HTTP请求可以利用HTTP头部自动地将来自用户的数据（又称为cookie）发送给服务器。无论是web页面还是服务器，都可以读/写这个数据。一般情况下，可以通过JavaScript的 document.cookie来访问cookie，而cookie通常是由一些名字和值对组成，如下所示：
CookieName1=CookieValue1; CookieName2=CookieValue2;

由于Cookie经常用来存储诸如认证证书之类的机密信息的，为了保护这些信息，RFC2109为其定义了类似于同源策略的安全策略。服务器定为 cookies的主控制器，服务器不仅可以对cookie进行读写操作，而且还能为cookie配置安全属性。cookie的安全属性如下所示：

1.Domain:这个属性的用途与同源策略类似，但是具有更多的限制。就像同源策略一样，domain在默认时为HTTP请求的Host头部中的域名，但是domain也可以设置成更高一级的域名。例如，如果HTTP请求的Host头部中的域名为x.y.z.com，那么x.y.z.com站点可把cookies设为用于所有*.y.z.com域，但是x.y.z.com站点却不能把cookies设为用于所有*.z.com——因为前面说过，只能比HTTP请求的Host头部中的域名高出一个级别，当然，任何域都不能将cookies设为用于顶级域名，如*.com，这是不允许的。

2.Path:这个属性是用来提高域安全模型的控制力度，使其包含URL路径。注意，属性path是可选的，如果设置了它，那么cookie只会发送给路径与属性path相吻合的那些服务器。例如，如果http://x.y.z.com/a/WebApp建立了一个路径属性设为/a的cookie；那么该cookie只会发送给所有http://x.y.z.com/a/*范围内的请求。但是，当人们向http://x.y.z.com/index.html或http://x.y.z.com/a/b/index.html的请求时，该cookie不会发送。

3.Secure:如果一个cookie设置了该属性，那么只有遇到HTTPS请求时才发送该cookie。注意，HTTP和HTTPS的响应都可以对属性secure进行相应的设置。因此，一个HTTP请求/应答可以改变HTTPS的cookie的secure设置。对于某些高级中间人攻击来说，这是一个大问题。

4.Expires:通常情况下，当浏览器关闭时，cookies就会被删除。不过，您可以设置一个截止日期，在此之前，cookies将一直存放在用户的机器上，并且对于每个HTTP请求都发送此cookie，直到期满为止。截止日期的格式一般为Wdy, DD-Mon-YYYY HH:MM:SS GMT。 通过设置属性expires为一个过去的日期，可以立即删除cookies。

5.HttpOnly:这个属性对于Firefox和Internet Explorer都是新增的。它在Web应用中很少使用，因为它只对Internet Explorer有效。如果这个属性被设置，那么IE 将不允许阅读该cookie，也不允许通过JavaScript的document.cookie对该cookie执行写操作。这个属性是用来防止攻击者窃取cookies来做坏事，不过，攻击者总是可以创建JavaScript来做等价的事情，所以即使不通过窃取cookies也无所谓。
下面是带有安全属性cookies的示例代码：

　　我们知道，像来自服务器端的JavaScript和VBScript代码可以通过访问变量document.cookie来对cookies进行读写操作，除非该cookie设置了HttpOnly属性并且用户正在使用IE。这是一个很大的安全隐患，黑客对此极为感兴趣，因为cookies通常含有认证证书，CSRF保护措施的信息和其他机密信息；此外，中间人攻击可以编辑HTTP通信中的JavaScript代码，呵呵，这简直就是一场恶梦。

如果一位攻击者可以突破或绕过同源策略的话，就可以通过DOM的变量document.cookie轻松读取cookies。另外，写入新的cookies也是非常容易的，攻击者只要使用类似下列字符串格式来连接document.cookie变量即可：

　　读者可以对照全面讲述的内容自己理解上述代码，我想这并非难事。

四、Cookies在创建和语法分析方面的安全隐患

Cookies可以用于JavaScript、浏览器、Web服务器、负载均衡系统及其他独立系统，每个系统都使用不同的代码来解析 Cookies。毫无疑问，这些系统将以不同的方式来解析和阅读cookies。攻击者也许能够将受害者已有的cookie中的一个替换掉，换上的 cookie在系统看来表面上跟想要的那个没什么两样，但是实际上内容却大相径庭了。

举例来说，攻击者也许能够添加一个cookie，而这个cookie恰好与受害者已有的cookies中的一个重名，这样攻击者就覆盖了原先的cookie。可以考虑一下大学的设置，其中一位攻击者具有一个公开的web页面，位于http://public-pages.daxue.edu/~attacker，同时该大学在https://webmail.daxue.edu/提供了一个webmail服务。攻击者可以自己制作一个cookie并且将域设为.daxue.edu，然后把它发送到https://webmail.daxue.edu/。假如这个cookie跟webmail用于认证的cookie同名的话，现在webmail系统读取的将是攻击者伪造的cookie，而不是webmail为用户所建立的cookie。

这时候，webmail系统会将发送该cookie的人（即攻击者）当作是其他的人对待，并进入被冒充的人（即受害者）的webmail帐户。之后，攻击者就可以对受害者中的邮件做手脚，让账户内只留下一封电子邮件，并声称用户的电子邮件由于安全原因而被屏蔽，该用户必须转到http://public-pages.Daxue.edu/~attacker/reAuthenticate(或者一个隐蔽的恶意链接）去重新登录才能看到他的所有邮件。攻击者可以建立一个重新认证连接，使其看上去像一个典型的大学登录页面那样要求受害者输入用户名和口令。当受害者递交个人信息后，用户名和口令会被发送给攻击者。
实际上，仅仅注入cookie片段也可以使不同的系统读取不同的cookies。注意，cookies和访问控制使用相同的符号进行分隔：分号(;)。如果攻击者可以通过JavaScript添加cookies，或者cookies是根据一些用户输入来添加的，那么攻击者可以附加一个 cookie片段，以利用该片段改变安全特性或者其它的cookies的值。

五、利用JavaScript将Cookie安全模型降低至同源策略
Cookie安全模型要比同源策略更安全一些，但是利用一些JavaScript，可以把cookie的域还原成跟同源策略的document.domain设置相同的安全级别，并且该cookie的path属性可以被完全绕过。
我们还是使用前面的大学webmail的例子，这里假设攻击者在http://public-pages.daxue.edu/~attacker/创建了一个web页面，同时该大学在http://webmail.daxue.edu/建有一个webmail系统。如果在http://webmail.daxue.edu/中的某个页面的document.domain="daxue.edu"，假设该页面为http://webmail.daxue.edu/badPage.html，那么攻击者可以通过诱导受害者到达http://public-pages.daxue.edu/~attacker/stealCookies.htm来窃取受害者的cookies，该页包含以下代码：

　　类似的，如果攻击者的个人页面位于http://www.daxue.edu/~attacker/，webmail系统位于http://www.daxue.edu/webmail/，同时webmail的cookie中的路径被设为path=/webmail，那么，攻击者就可以通过诱使受害者浏览 http://www.daxue.edu/~attacker/stealCookies.html来窃取受害者的cookie，其中这个页面包含如下所示的恶意代码：

　　六、保护Cookie
利用Cookie安全模型中添加的特性，但是不要完全依赖Cookie安全模型中的添加的安全特性。只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。

七、Flash的安全模型
Flash是一种流行的Web浏览器插件，它近来发行的版本中包含了很多复杂的安全模型以供开发人员根据自己的喜好进行定制。这里我们将介绍Flash的安全模型的各个方面，首先介绍的是JavaScript所不具备的那些特性。
Flash的脚本语言称为ActionScript，它与JavaScript非常类似，并且包含了一些从攻击者的角度看来非常感兴趣的一些类：
1.Socket类使开发人员可以创建至allowed域的原始TCP套按字连接，这可以用来达到各种目的，比如精心制作带有伪造的各种报头（例如referrer）的HTTP请求。此外，套按字也可用于扫描无法从外部访问的网络计算机和端口。　　
2.ExternalInterface类使开发人员可以从Flash运行浏览器中的JavaScript，以达到各种目的，例如读写document.cookie。
3.XML和URLLoader这两个类可以以某用户的名义发送HTTP请求（连带浏览器的Cookie）至allowed域，以达到各种目的，例如跨域请求。
默认时，Flash的安全模型与同源策略非常类似。即，来自于某个域的Flash应用只可以读取来自该域的响应。此外，Flash还对HTTP请求的发送做了一些安全限制，但是您可以经过Flash的getURL函数发送跨域的GET请求。此外，Flash不允许通过HTTP装入的Flash应用程序读取用 HTTPS载入的响应。需要注意的是，如果在另一个域上的安全策略准许跟Flash应用程序所在域通信的话，Flash却允许跨域通信。安全策略通常是一个名为crossdomain.XML的XML文件，一般位于域的根目录下。从安全角度讲，最糟糕的策略文件可能是下面这样：

　　该策略允许任何Flash应用程序跟存放这个crossdomain.xml文件的服务器(跨域)通信。该策略文件可以任意取名，并且可以放在任何目录下。可以使用下列ActionScript代码加载任意的安全策略文件：
System.security.loadPolicyFile("http://public-" +"pages.univeristy.edu/crossdomain.xml");
如果它不在服务器的根目录中，那么该政策仅适用于该策略文件所在的目录以及该目录下的所有子目录。举例来说，假设策略文件位于http://public-pages.daxue.edu/~attacker/crossdomain.xml，那么该政策将适用于对http://publicpages.daxue.edu/~attacker/doEvil.html和http://public-pages.daxue.edu/~attacker/moreEvil/doMoreEvil.html的请求，而不对诸如http://public-pages.daxue.edu/~someStudent/familyPictures.html或http://public-pages.daxue.edu/index.html这样的页面有影响。

八、反射策略文件

策略文件会被Flash“宽大地”解析，因此，如果您可以构造一个会导致服务器发回一个策略文件的HTTP请求，Flash将接受该策略文件。举例来说，http://www.daxue.edu/CourseListing?format=js&callback=<cross-domain-policy><allow-accessfrom%20domain="*"/></cross-domain-policy>这个Ajax请求

将得到如下所示的响应：

这样会导致该Flash应用程序能够得以跨域访问http://www.daxue.edu/。
也能您已经想到了，如果人们可以上载一个文件到包含一个不安全的策略文件的服务器并能够随后在通过HTTP进行检索的话，那么System.security.loadPolicyFile()函数也会跟这个策略文件关联起来。

总之，Flash将遵守任何包含跨域策略的文件，除非</cross-domainpolicy>之前存在任何未闭合的标签或者扩展ASCII字符。注意，Flash Player会完全忽略MIME类型。

九、针对策略文件反射的保护措施

当把用户定义的数据返回给该用户时，应当把HTML中的大于号〉换码为&gt;并且把字符<转换为&lt;，或者直接将其删除。

十、结束语

在浏览器中已经建立了一些安全措施——即同源策略和Cookie安全模型。此外，一些浏览器插件，诸如Flash Player、Outlook Express 以及Acrobat Reader等，带来了更多的安全问题和安全措施。然而，如果攻击者可以强迫用户执行源自特定域的JavaScript的话，这些额外的安全措施总是倾向于削弱同源策略的力量。

跨站点脚本攻击（XSS）技术能够强迫用户执行攻击者以受害者名义在某个域上选择的脚本，如JavaScript、VBScript、 ActionScript，等等。XSS要求某个域上的Web应用程序能够提供（即供应、返回）被攻击者所控制的字符。因此，攻击者可以向页面注入代码，而这些代码将来会在这个有弱点的域的上下文中执行。攻击者精心构造出供受害者运行的恶意代码之后，他还必须诱骗受害者单击一个链接。该链接一经点击，马上就会启动攻击活动。这些内容将在下一篇中加以介绍。

一、拒绝特殊字符

　　问：我对防御跨站脚本攻击（XSS） 很有兴趣。如果我拒绝使用<、 >、脚本——以及容易导致恶意攻击的同等实体参数——这样的字符和词语，那么就会增加应用开发的成本。你会推荐这种“作战”方式吗？

　　答：不，相反，我推荐开发人员在他们的应用代码中只允许适应应用功能所必需的规定字符。这是应用开发的最佳做法。

　　很多企业都把安全代码作为在开发过程的最后才会发生的事情。但是，如果在开发周期的最后阶段测试应用的人说应用需要记录来保证安全性，那么应用就需要重写并重新测试，与之相结合的其他应用也是如此。这种持续的矛盾比在安全开发周期中进行的不断地安全过程成本高得多。

　　如果有一种领域称为“稳定”，例如，就没有理由允许<、>、;、*、--或者:作为可能参数。如果应用开发人员写的代码只允许接受已知的良好参数，就会通过减少质量担保和认证以及信赖测试的成本降低应用开发的整体成本。

二、利用HTTP-only Cookie缓解XSS之痛

以下内容来自51CTO，原文：http://netsecurity.51cto.com/art/200902/111143.htm

　　在Web安全领域，跨站脚本攻击时最为常见的一种攻击形式，也是长久以来的一个老大难问题，而本文将向读者介绍的是一种用以缓解这种压力的技术，即HTTP-only cookie。

　　我们首先对HTTP-only cookie和跨站脚本攻击做了简单的解释，然后详细说明了如何利用HTTP-only cookie来保护敏感数据，最后介绍了实现HTTP-only cookie时确定浏览器版本的具体问题。

　　1、XSS与HTTP-only Cookie简介

　　跨站点脚本攻击是困扰Web服务器安全的常见问题之一。跨站点脚本攻击是一种服务器端的安全漏洞，常见于当把用户的输入作为HTML提交时，服务器 端没有进行适当的过滤所致。跨站点脚本攻击可能引起泄漏Web 站点用户的敏感信息。为了降低跨站点脚本攻击的风险，微软公司的Internet Explorer 6 SP1引入了一项新的特性。

　　这个特性是为Cookie提供了一个新属性，用以阻止客户端脚本访问Cookie。

　　像这样具有该属性的cookie被称为HTTP-only cookie。包含在HTTP-only cookie中的任何信息暴露给黑客或者恶意网站的几率将会大大降低。下面是设置HTTP-only cookie的一个报头的示例：

　　Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly

　　上面我们介绍了HTTP-only Cookie；下面我们开始向读者介绍跨站点脚本攻击、允许通过脚本访问的cookie所带来的潜在危险以及如何通过HTTP-only来降低跨站点脚本攻击的风险。   

　　跨站点脚本攻击是一种服务器端常见的安全漏洞，它使得黑客可以欺骗用户从而导致用户在某个Web 站点上的敏感信息的泄漏。下面通过一个简单的示例来解释一个跨站点脚本攻击的相关步骤。

　　2、跨站点脚本攻击示例

　　为了解释跨站点脚本攻击是如何被黑客利用的，我们假想了下面的一个例子：

　　A证券公司运行了一个Web 站点，该站点允许您跟踪某股票的最新价格。为了提高用户体验，登录A证券公司的Web 站点之后，你将被重定向到www.azhengquan.com/default.asp?name = < script > evilScript()< / script >张三，并且有一个服务器端脚本生成一个欢迎页面，内容为“欢迎您回来，张三！”。

　　你的股票数据被存放在一个数据库中，并且Web 站点会在你的计算机上放置一个cookie，其中包含了对这个数据库非常重要的数据。每当你访问A证券公司站点时，浏览器都会自动发送该cookie。

　　一个黑客发现A证券公司公司的Web 站点存在一个跨站点脚本攻击缺陷，所以他决定要利用这点来收集你所持股票的名称等敏感信息。黑客会您你发送一封电子邮件，声称您中奖了，并且需要点击某个链接如“点击这里”来领取奖品。注意，该链接将超链接到www.azhengquan.com/default.asp?name=< script >evilScript()< / script > 当您点击这个链接，映入眼帘您的将是“欢迎您回来！”—— 等等，您的姓名哪里去了？事实上，单击电子邮件内的链接之后，你实际上就是在通知A证券公司公司的Web 站点，你的姓名是< script  > evilScript()<  /script >。Web服务器把用这个“名字”生成的HTML返回给你，但是你的浏览器会把这个“名字”作为脚本代码解释，脚本执行后便出现了我们前面看到的一 幕。一般情况下，支持客户端脚本是浏览器的典型功能之一。如果这个脚本命令浏览器向黑客的计算机发回一个cookie，即使这个cookie包含有您的股 票的有关信息，您的浏览器也会老老实实地执行。最后，那些来自A证券公司的Web 站点的指令获取了那个包含敏感信息的cookie。

　　下面是跨站脚本攻击的示意图，它详细的展示了攻击的五个步骤。首先，用户点击了黑客发来的电子邮件中的一个嵌入的链接（第1步）。由于跨站点脚本攻 击缺陷的原因，这样会导致用户的浏览器向Web 站点发送一个请求（第2步）；服务器端根据该请求会生成一个包含恶意脚本的响应，并将其发回给用户的浏览器（第3步）。当用户的机器执行返回的恶意代码时 （第4步），就会将用户的敏感数据发送给黑客的计算机（第5步）。

图1

　　我们可以看到，这个过程只需要用户单击了一个链接，然后就会有指令发送给Web服务器，然后Web服务器生成一个嵌入恶意脚本的网页；浏览器运行这个来自受信任的源的脚本，却致使信息泄漏给黑客的计算机。跨站点脚本攻击有许多不同的形式，这里只是其中的一种。

　　3、用HTTP-only Cookie保护数据

　　为了缓解跨站点脚本攻击带来的信息泄露风险，Internet Explorer 6 SP1为Cookie引入了一个新属性。这个属性规定，不许通过脚本访问cookie。使用HTTP-only Cookie后，Web 站点就能排除cookie中的敏感信息被发送给黑客的计算机或者使用脚本的Web站点的可能性。

　　Cookie通常是作为HTTP 应答头发送给客户端的，下面的例子展示了相应的语法（注意，HttpOnly属性对大小写不敏感）：

　　Set-Cookie: =[; =]
　　[; expires=][; domain=]
　　[; path=][; secure][; HttpOnly]

　　即使应答头中含有HttpOnly属性，当用户浏览有效域中的站点时，这个cookie仍会被自动发送。但是，却不能够在Internet Explorer 6 SP1中使用脚本来访问该cookie，即使起初建立该cookie的那个Web 站点也不例外。这意味着，即使存在跨站点脚本攻击缺陷，并且用户被骗点击了利用该漏洞的链接，Internet Explorer也不会将该cookie发送给任何第三方。这样的话，就保证了信息的安全。
注意，为了降低跨站点脚本攻击带来的损害，通常需要将HTTP-only Cookie和其他技术组合使用。如果单独使用的话，它无法全面抵御跨站点脚本攻击。

　　4、支持HTTP-only Cookie的浏览器

　　如果Web 站点为不支持HTTP-only Cookie的浏览器建立了一个HTTP-only cookie的话，那么该cookie不是被忽略就是被降级为普通的可以通过脚本访问的cookie。这还是会导致信息容易被泄露。

　　对于公司内部网中的web页面，管理员可以要求所有用户都是由支持HTTP-only Cookie的浏览器，这样能保证信息不会由于跨站点脚本攻击缺陷而泄露。

　　对于公共Web 站点，由于需要支持各种各样的浏览器，这时可以考虑使用客户端脚本来确定不同访问者所使用的浏览器的版本。Web 站点可以通过向支持～的浏览器发送敏感信息以减轻跨站点脚本攻击对Cookie的威胁。对于那些使用不支持HTTP-only Cookie的浏览器的访问者，可以限制为其提供的信息或功能，并要求升级他们的软件。

　　当确定Internet Explorer的版本时，重要的是记住Internet Explorer 6 SP1 的用户代理字符串跟Internet Explorer 6的用户代理字符串是一样的。客户端脚本还必须使用navigator对象的appMinorVersion属性检测主版本号，这样才能确定出客户端是否 安装了Internet Explorer 6 SP1。

　　5、小结

　　在Web安全领域，跨站脚本攻击时最为常见的一种攻击形式，也是长久以来的一个老大难问题，而本文将向读者介绍一种用以缓解这种压力的技术，即 HTTP-only cookie。我们首先对HTTP-only cookie和跨站脚本攻击做了简单的解释，然后详细说明了如何利用HTTP-only cookie来保护敏感数据，最后介绍了实现HTTP-only cookie时确定浏览器版本的具体问题。