易栈网-膘叔

当然，这不是我说的话，不过，要是我说的话，我也不会升级到IE8.
身为一名WEB开发人员，要考虑的是使用量最多的浏览器的用户，那，无非就是IE6、IE7和FF、opera等用户了，甚至，chrome我们也无须过多考虑，毕竟这部分的用户太少了，而且即使要考虑也很方便，毕竟除IE外，其他浏览器都是支持W3C标准的。所以，IE8在没有占有市场份额很大前，我也是不会升级的。最多找找那种多浏览器兼容软件进行测试的时候会用用，其他时候，一概不做考虑。

这名作者又是怎么说的呢？让我们来看看：

E8发布以来，在Twitter及不少SNS都收到朋友们的留言，询问我对IE8的评价。我没有升级，也不太愿意升级，只能先求助于他人。无奈，我 目前还真没看到什么让我心动的“评测”，我想，也许是IE8正式版本身并没有带给我们（如果给您惊喜了，请留言告知）太大的惊喜吧。更何况，我很担心安装 好IE8之后，我的那些只能在IE下使用的插件、网站是否能继续正常运转。尤其是看到Fenng的一推（“各位安装了 IE8 不能用支付宝的朋友，别问我了。这事儿我决定不了”），让我还是忍住了没去点击那个已经下载完毕的安装包。

我觉得写一篇不负责任的评测毫无乐趣，而且，IE8也与我毫无吸引之力。作为一个转型回ActionScript开发（是的，AS的世界比Web开 发单纯许多，屁事儿也少很多）的开发者，我对它能多好地支持CSS、JavaScript也基本没有兴趣了（我承认在beta版时曾经很喜欢它的一些创 意，例如Debugger模块和插件开放）。作为一个用户，IE8也没有任何让我升级的理由。对于一个拥有IE6、IE7的用户来说，升级一个IE8甚至 还不如下载一个Chrome的安装包快吧（你比较过么？如果我错了，请留言告诉我测试结果）。IE8的几个新特性，我觉得在其他浏览器中已经全部都具备了。

总之，我没有升级到IE8，而且，如果你平时多用Chrome和Firefox，我觉得也毫无升级到IE8的必要。如果你仍然对IE8究竟是怎么回事充满好奇，可以推荐看看我的一位校友的博客文章（这里）。

评测都是扯淡，让我们用数据说话（为了尽量客观，数据来自Analytics，选自awflasher.com域名下下非技术类文章，如果你好奇具体如何筛选可见此文）：

以下是IE8正式发布之后，8.0版本占所有IE浏览器的百分比（占所有浏览器的比比这还要低），这还包括了相当一部分beta版用户（根据这个时间段之前三天的统计，估计能有1.34%左右），也就是说，大多数IE用户并没有太热衷升级到8.0

这是去年9月份Chrome发布时前2天的数据，Chrome已经占到所有浏览器的2.76%了：

当然，IE8的出现如果能进一步消灭IE6用户，我觉得还是颇有意义的（可以为我们Web开发者省很多时间），可是，这件连IE7都没有完成好的任务，IE8真的能做到么？

原文：http://www.awflasher.com/blog/archives/1731
是呀，在这么低的市场份额下，如果我们要考虑兼容，那么付出的代价非常大，而事实上，这部份用户，却大多是WEB开发人员，你说平时一普通人，谁TMD会去升级呀，又要考虑不稳定，说不定连网银也不能用了。你会用吗？

CB纯粹是一堆程序员发泄的地方，因此，在上面不可避免的会出现一些好的东西，比如这个：9 个基于JavaScript 和 CSS 的 Web 图表框架

图表，我个人还是觉得用FLASH来做比较好，比较有动感，而且现在所有浏览器都支持FLASH。它还是比较有前途的。FLASH和JS在运行的时候占用CPU应该是JS相对较高吧？FLASH图表还是有一些很不错的。比如open flash chart，就是一个开源的FLASH图片控件。

不过，标题是JS的，我当然还是把CB原文贴过来喽：http://www.cnbeta.com/articles/79418.htm

原文如下：

新闻来源:woork.blogspot.com
jQuery, MooTools, Prototype 等优秀的 JavaScript 框架拥有各种强大的功能，包括绘制 Web 图表，使用这些框架以及相应插件，我们可以非常轻松地实现曲线图，圆饼图，柱状图等 Web 图表的绘制，而不必象以往那样通过复杂的 Flash 技术实现。本文介绍了9个优秀的基于 JavaScript 与 CSS  的 Web 图表框架。
jQuery, MooTools, Prototype 等优秀的 JavaScript 框架拥有各种强大的功能，包括绘制 Web 图表，使用这些框架以及相应插件，我们可以非常轻松地实现曲线图，圆饼图，柱状图等 Web 图表的绘制，而不必象以往那样通过复杂的 Flash 技术实现。本文介绍了9个优秀的基于 JavaScript 与 CSS 的 Web 图表框架。
1. Flot


Flot 是一个纯粹的 jQuery JavaScript 绘图库，可以在客户端即时生成图形，使用非常简单，支持放大缩小以及鼠标追踪等交互功能。该插件支持 IE6/7/8, Firefox 2.x+, Safari 3.0+, Opera 9.5+ 以及 Konqueror 4.x+。使用的是 Safari 最先引入的 Canvas 对象，目前所有主流浏览器都支持该对象，除了 IE, 因此在 IE中使用 JavaScript 进行模拟。这里有一些实例。
2. JS Charts


JS Charts 是一个免费的基于 JavaScript 的图表生成器，表格绘制非常简单，几乎不需要编码，也不需要插件和服务器模块，使用XML 或 JavaScript 数组缓存数据。
3. TableToChart
TableToChart 是一个 MooTools 脚本，可以将 HTML Table 对象中存储的数据绘制成图表。你可以使用 table 标签生成图表，柱状图，曲线图，圆饼图等。
4. PlotKit
PlotKit 是一个 JavaScript 绘图库，支持 HTML Canvas 标签，也支持 SVG。
5. Yahoo UI Charts Control


YUI Charts Control 可以在网页上将表格数据转换为图表，支持柱状图，曲线图以及圆饼图。支持 DataSource 工具，可设置的轴，鼠标盘旋提示，图表组合，以及皮肤等功能。
6. ProtoChart


ProtoChart 是一个基于 Prototype 和 Canvas 标签的开源库，这个库深受 Flot, Flotr, Plotkit 等启发，支持曲线图，柱状图，圆饼图等，可以在同一个图表上显示多套数据，支持可定制的图例，网格，边界以及背景图。支持 IE6/7, Firefox 2/3 以及 Safari，甚至支持 iPhone.
7. EJSChart


EJSChart 支持鼠标追踪，鼠标事件，按键追踪与事件，缩放，滚动，交互等功能，将用户体验上升到一个新高度。支持曲线图，面积图，离散图，圆饼图，柱状图等形式，拥有完备文档的属性和方法可以帮助实现很好的定制。
8. fgCharting
fgCharting 是一个很出色的 jQuery 插件，支持多种图形。
9. Pure Css Data Chart


以往的数据展示往往通过 flash 实现，现在，我们可以通过纯粹的 CSS 实现类似的功能。CSSGlobe 有一个非常实用的教程帮你实现基于 CSS 的绘图，甚至不需要 JavaScript。

本文国际来源：http://woork.blogspot.com/2009/03/useful-scripts-to-plot-charts-in-web.html
中文翻译来源：COMSHARP CMS 官方网站

本软件是我非常喜欢的软件之一，为防止哪天某些网站被和谐了，留下来做个备份

介绍：Paragon Partition Manager是一个类似于PQ PartitionMagic的磁盘分区工具集，是一套磁盘管理软件，PartitionMagic的最佳替代品！有着直觉的图形使用介面和支持鼠标操 作。主要功能包括：能够不损失硬盘资料下对硬盘分区做大小调整、能够将NTFS文件系统转换成FAT、FAT32或FAT32文件系统转换成FAT文件系 统、支持制作、格式化、删除、复制、隐藏、移动分区、可复制整个硬盘资料到其它分区、支持长文件名、支持FAT、FAT32、NTFS、HPFS、 Ext2FS分区和大于8GB大容量硬盘。
本软件的特色在于，可以自由选择语言代码页来进行分区转换，从而可以在任何语言的分区上进行操作。而 PQ PartitionMagic在简体中文环境下进行 FAT32<->NTFS 的转换时会有乱码产生，而Paragon Partition Manager却不会有乱码问题。
此为服务器版，支持 Windows NT4/2000/2003
汉化注意事项：
1、此为零售简装版，不需要原版，直接安装后即可使用。去掉了不常用的组件，只保留 Partition Manager 和 ImageExplorer。
2、为减小安装包的大小，只保留了英语、简体中文和繁体中文的代码页文件，也就是说，此三种语言的操作系统在转换文件系统时不会有任何乱码问题，如需其他特殊语言代码，请安装原版。
3、为确保转换正确，请按以下进行设置：选择菜单“常规--设置”，再选“本地信息”，时区选择“北京、香港”，文件名语言选择“Chinese(RPC)”，然后确定即可。
4、 在2004年初即已获得作者授权做官方简体中文版，不过全部完成后，德国佬却音讯全无，不再给我回信，所以至今也没有发行官方中文版。此版是我根据作者以 前给的资源结合新版资源做成的，因汉化方法特殊，新增的资源只能一条条查找并自己加到语言包中，所以有遗漏在所难免。另外，部分地方会有乱码，原因未知。

原文：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时确定浏览器版本的具体问题。