易栈网-膘叔

为之漫笔的博客是我比较喜欢订阅的博客之一，这其中有一部分是因为他关注的内容同样是我关注的对象之一，还有一部分原因是他还是我关注内容的书籍的翻译人员。比如现在的这本《Flex3实战》，现在还不知道何时能够上市，先来看看序吧。

原文地址：http://www.cn-cuckoo.com/2009/03/21/flex3-in-action-preface-532.html

Tariq Ahmed

多年来，我一直都在找寻一种方式，一种能够带给用户更好的在线体验的方式。而且，这个找寻历程从Google革命性的Google Maps站点引起轰动之前就已经开始了。我的意思是说，Web用户在很长一段时间里，都不知道还能有什么更好的在线体验。

在把Web当作文档发布系统使用的若干年里，用户体验曾一度在强大的本地桌面应用和乏善可陈的HTML应用之间摇来摆去。但是，贫乏的用户体验并没 有对HTML和Web构成冲击——Web作为平台中立的文档发布系统，事实上是非常名符其实的。开发人员和公司专注于Web是因为它支持快速应用程序开 发，而用户之所以接受眼前的一切则是由于——嗨！Web应用程序就是这个样子的。真的就是这个样子吗？

有件事曾令我百思不得其解。每次点击都会导致后台系统执行许多代码，而结果反映到UI上却只是一点点变化。而比这更糟的则是对数据库服务器频繁密集 的访问。对一名技术人员来说，解决这个问题最简便的办法就是多加内存、使用虚拟机装载，或者少花钱多采购一些杂牌服务器，然后大功告成。但是，我更关心用 户要为此付出什么代价。他们会对Web应用程序中常见的点击加等候习以为常；而且，对UI也没有多大的操作自由。不错，可以使用JavaScript；然 而，这只是在掌握更高级技术之前的选择。从投入产出角度讲，这样做往往得不偿失。

这时候，Java Applet和Flash问世了，而且乍一看它们正是我要找寻的东西。实际上，Applet作为一个解决方案并不合适，它的体积太大，下载也很慢，况且不 能跨平台使用。Flash挺有希望的，可是在设计师的工作环境中创建企业级应用程序，仍然不免有缘木求鱼的味道。

我在eBay的知识管理部门工作期间，也遇到了相同的问题。我需要找到一种方式，能够抽象出数据的复杂性，并且能让用户在可视的环境中方便地操作这些数据。

既而，Flex在2004年发布了（最初是V1，很快就是V1.5）。我当时有权作出采用它的决定，我们的团队也因使用它而感受到了完全不一样的体验。当时，我就知道Flex前途无量。因为Flex应用程序既具有桌面应用程序的强大特性，又能满足软件团队快速开发的需求。

作为Flex支持者，我把推动Flex社区发展当作自己的一项使命。我创建了CFLEX.Net（www.cflex.net），并坚信这个社区的规模越大，通过知识和代码共享产生的反推力也将越大，借此就可以促进这项技术的更快普及。毕竟，强有力的支持网络可以降低在组织中引入新技术的风险。

作为较早采用Flex的人，我在学习Flex的过程中走过不少弯路。主要原因是当时缺少相关书籍和参考资料。这种局面在Flex 2发布后得到了改观，大量的学习资源开始涌现。

我在2005年底离开eBay加入Amcom Computer Services，并在那里创建和管理一个开发团队。同学习任何新技术一样，要熟练掌握Flex也不容易。因此，最好的办法就是不断提升技能。在培训开发 人员使用Flex的过程中，我发现市面上的某些图书常常言不及义，很多显而易见的问题都没有提到。

为了进一步推动Flex社区的发展，我决定写作本书，希望它能解决读者经常会遇到的问题。本书一反按功能特性布局谋篇的常见模式，改为按创建应用程 序的自然进程组织内容。我只在必要时介绍必要的知识，不会过早地讨论复杂主题。同时，着意缩短的示例代码，也将有助于读者理解和上手。另外，我还发现把新 事物与已知事物联系起来，可以增强学习效果。因此，在适当的情况下，我会尽可能拿其他技术的实现原理来进行类比。

希望读者通过阅读本书能够深入理解Flex，并最终加入到Flex社区中——因为届时你也能够向周围的人共享自己的知识和经验。

而现在，则是准备学习Flex的时候。随着社区逐步发展壮大，越来越多第三方厂商会发布与Flex有关的技术，Flex用户组也会在世界各地不断涌现。

随着其他厂商的先后跟进，RIA领域将迅速升温——Adobe再次证明自己走在了前列。我们正处于一个令人振奋的时代！以HTML为基础的Web应 用程序始终会占有一席之地；然而，现在是该把你的技能提升到一个新高度的时候了。因为，这个产业的向前发展不会以个别人的意志为转移。

现在请坐下，系好安全带，旅行就要开始了！

TARIQ AHMED

当然，这不是我说的话，不过，要是我说的话，我也不会升级到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应用程序能够提供（即供应、返回）被攻击者所控制的字符。因此，攻击者可以向页面注入代码，而这些代码将来会在这个有弱点的域的上下文中执行。攻击者精心构造出供受害者运行的恶意代码之后，他还必须诱骗受害者单击一个链接。该链接一经点击，马上就会启动攻击活动。这些内容将在下一篇中加以介绍。