易栈网-膘叔

信息架构的定义

根据维基百科的定义，信息架构（Information Architecture， 简称IA）是在信息环境中，影响系统组织、导览、及分类标签的组合结构。它是基于信息架构方法论，并运用计算机技术 管 理和组织信息的一个专门学科。信息架构并非一开始就应用于网站设计，其起源于情报科学，最初应该是用于图书馆等地方的信息组织和信息检索的。

《用户体验的要素——以用户为中心的WEB设计》这本书中对信息架构的定义基于网站设计：信息架构着重于设计组织分类和导航的结构，从而让用户可以 提高效率、有效地浏览网站的内容。

具体的就不再多说的，可能各有各的理解，这里直接来看一个实例——Wordpress的信息架构模式：

当然，上面这个图只能展示一个大体的网站信息架构，中间的类目层也许不止一层，会有大类、子类、子子类……底层可以是文章也可能是页面或者一些其他 的具体内容。而网站的内部关系也往往因为全局或局部导航、网站内链和内容关联等功能的存在而复杂的多，图上的箭头也会密集很多，但我们无需罗列所有内容间 的关系，关键是在理清基本的结构。

信息架构的类型

还是参考《用户体验的要素——以用户为中心的WEB设计》中对信息架构的几个分类：

层次结构（Hierarchical Structure）

也叫树形结构，是最常见的网站信息架构模式，上面举例的Wordpress的信息架构就是典型的层次结构。树形结构中箭头的方向不一定是自上而下 的，也可能是自下而上或者是双向的，而内容层之间也会因为一些关联链接的存在而存在同层次间的指向箭头。

矩阵结构（Matrix Structure）

矩阵结构比较注重“维”的概念，即从多维的角度来检索信息，如时间、地域、内容分类等，典型的应用就是内容管理系统（CMS）网站或者电子商务类网 站，比如你浏览豆瓣的电影时可以筛选：2010年—美国—科幻，也许这个时候《钢铁侠2》就呈现在你面前了。

线性结构（Sequential Structure）

看到线性结构也许你马上会想到面包屑，它将网站中最重要的一个信息架构路线展现了出来，即使它无法为你提供你在网站上的平面坐标，但至少它显示了你 现在正处于关键线路的哪个点上；当然，网站的一些关键路径一般也是按照线性结构涉及的，比如用户注册流程或电子商务网站的购买流程等。

网站分析与信息架构

根据网站业务模式的不同，可以选择适合自己网站的信息架构的模式，无论是上面的哪种信息架构模式，只要设计和运用合理，用户便能够在你的网站上以最 方便的形式、最快的速度找到他们需要的信息。

但当我浏览某些网站时，有时真的会让我感觉到“找不到北”，结果就是直接关闭该页面，如果不希望让已经进入了你的网站的用户轻易地离开，网站信息架 构的好坏将直接影响网站的用户体验。所以我们需要通过一些方法来检验网站的信息架构是否满足用户的信息检索的需求。

1.尝试整理出类似上面例子中的网站信息架构图

这个是最简单最直观的方法，如果你的网站信息架构足够清晰，那么画出这样的图对你来说也绝非难事；而当网站的应用比较复杂、内容比较宽泛，那么可能 要整理出网站的整体信息架构就会相对困难，但我相信一个设计优秀的网站只要稍加整理，大体的信息架构图还是画得出来的；而当你绞尽脑汁就是理不清你的网站 的信息架构的头绪的时候，那么说明你的网站需要优化了。

2.通过网站分析的方法验证信息架构的合理性

本文的副标题是“让用户更容易地找到需要的信息”，所以我们需要分析用户是否能够在你的网站上方便快捷地找到他们需要的信息，这里推荐一种方法—— 寻找网站中的迷失用户（Lost Visits）。

在一个合理的信息架构下，大多数的用户是不会在你的网站上迷路的；反之，混乱的信息架构会导致大量的用户迷失方向，就像是进入了一个巨大的迷宫。那 么如何寻找这些迷失用户？我们可以先分析下这类用户的行为，最明显特征的就是：连续点击好几个页面，每个页面都只是初步浏览（因为没有找到他们需要的信 息）就转到另外的页面或直接离开了。所以我们可以借助网站分析中的两个度量：

浏览页面数（Depth of Visit）：一次访问中用户总的浏览页面数；

页面平均停留时间（Avg. Time on Page）：一次浏览中用户在每个页面的平均停留时间，即该次访 问总停留时间（Time on Site）/该次访问页面数（Depth of Visit）。

我们可以用户细分的方法把那些浏览页面数较多，但页面平均停留时间较短的用户浏览看作是迷失用户，具体的数值可 以根据网站自身的特点进行定义，比如我定义我的博客中浏览页面数大于等于4，而页面平均停留时间小于等于15秒的Visits为迷失用户的浏览行为，我们 可以借助Google Analytics中的高级群组（Advanced Segment）来 区分出这类用户，关于如何使用Google Analytics的高级群组功能，可以参考蓝鲸的文章——Google Analytics功能篇—高级群组，如下图：

当然，你可能会说这种用户区分的方法不准确，这类用户不一定就是迷失用户，也有可能他们确实找到并浏览了具体内容，但因为内容不够吸引人或者其他原 因而马上离开了该页面。所以这里用高级群组划分出来的这类Visits的数量不能看作是迷失用户的一个绝对数值，我们只能认为里面的大部分Visits都 是迷失用户，而不排除存在某些另类。所以更合理的方法是通过计算这类Visits占网站总Visits的比例情况来分析网站的信息架构到底是否合理，我们 可以在Google Analytics上面选取网站的All Visits和Lost Visits进行比例和趋势的比较，如下图：

网站中迷失用户浏览的所占比例只需通过Lost Visits/All Visits就可以计算得到，但这个时候你还是无法根据这个计算结果来评判网站的信息架构到底是好是坏，因为还缺少一个基准线（Benchmark）或 者说是评判标准。在Google Analytics上面的Visitors标签下，提供了“Sites of similar size”的基 准比较（Benchmarking），你可以选择与你的网站相似类型的网站作为基准线进行数据比 较，这的确是个很好的参考，因为通过比较能够更加明确你的网站在同类型网站中的优势和劣势，为网站优化指明方向。GA借助其强大的数据平台可以为我们提供 基准线，但也许对于上面这个例子会显得无能为力，这个时候需要我们理性地自己去选择一个合适的基准线，比如我的博客目前类目和内容都还比较少，那么我可能 会定义我的网站的迷失用户比例应该控制在1%以下；但如果对于一个应用和内容比较复杂的网站，那么基准线显然会需要定得更高一点。一旦某段时间的数据越过 了基准线，就需要关注一下网站的信息架构是不是在趋于混乱了，是不是该进行一下整理和优化了。

总之，一个好的信息架构能够帮助用户更容易地找到他们需要的信息，从而有效地提升网站的用户体验，所以，尝试着去优化下你的网站的信息架构。如果你 有更好的方法能够有效地检验网站的信息架构的优劣，或者能够明确地分析得到网站信息架构的哪些细节上存在缺陷，希望能与我交流，我期待网站分析方法在优化 网站信息架构方面的更多的应用。

原文来自：《优 化网站信息架构》。

不过，如果你看过《胜于言传》这本书，其实就会发现，上面的内容和该书有一点雷同，只是胜一书中讲的更多的是如何改善用户体验，让用户看到更多的东西（指有效内容），如果你没有读过，还真是推荐看一下的。点击进入当当书店选购该书。

该书在当当中可是没有差评的，书的简介也真的很简单：

无论是居家还是办公，只要是在网上，我们通常都想快速地获取和使用信息。我们上网不是为了寻求某些问题的答案，就是为了完成某些任务——搜集信息、只阅读 我们需要的内容。我们都很忙．根本没有时间阅读网站中的太多内容。
本书会帮你为网站用户成功地撰写内容。它为网站内容的创建和修改提供了相应的策略、流程和方法。它有助于你对网站内容进行规划，组织、撰写、设计和测试， 从而吸引用户不断地光顾你的网站。
Ginny Redish大师介绍了如何创建有用、可用的网站内容。Ginny大师曾指导过许多写作人员、信息设计人员和内容负责人员，向他们传授过编写网站的原则和 秘诀。帮助他们创建了易于浏览、易于阅读且易于使用的网站信息。
这本具有实践性和教育性的书籍可以帮助所有创建网站内容的人更出色地完成他们的工作。
本书特色：
·全书用全彩图和来自真实网站的例子 清晰地阐述了内容编写原则。
·实例中带有改进前后的对比效果，写作的风格简明易读。
·包含针对网络版新闻稿、网络版法律声明和网 络版其他文档的具体原则。
·为了让有特殊需求的人们也可以使用网站，介绍了相关的编写技巧。

如果真想把内容当成主打对象，这本书还是值得购买的。

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

本文是从网上COPY而来，本文原始网址为：http://www.wlue.cn/html/200863124143.html，属于SEO一类的文章，对于文章中的一些见解，如果我有不同看法，我会以不同颜色的文字标出。
请看全文：

      对于服务器租用者来说，要想在硬件环境、网络环境等来改善自身网站性能，受客观因素的影响可能会有比较大的难度。因此，只能退而求其次，在程序上狠下功 夫。对于独立博客站长来说，使用的博客程序一般都是比较成熟的发行版的程序，这些程序为了适用的广泛性往往在代码中留出了很大的改进余地，因此，我们可以 在这上面下一些功夫。

　　提高博客性能方法一： 合并JavaScript文件。

     无论是在PJBlog还是其它的博客程序中，都使用了大量的外部JavaScript文件，要知道，引入一个外部文件都要 发送一个HTTP请求，而在所有影响页面响应速度的因素中，HTTP请求是最关键的一个，因此把所有的JavaScrip文件合并到一个 javascript.js的文件中是一个很好的做法。不过，你要注意不同的JavaScript文件中使用了不同的变量和函数名称，你要保证它们合并之 后还能正常工作。在某些情况下，你也可以有两个独立的JavaScript文件;

　　提高博客性能方法二：精减你的JavaScript文件。

      合并 JavaScript文件是为了减少HTTP请求次数，但是基本上不会在体积上有所改观，所以你还需要精简掉JavaScript文件中那些没有用的东 西，比如注释、换行、空白等，这大概会使你的程序缩小20%~30%的空间。你可以使用ESC 1.14对文件进行压缩，它的压缩率高达60%以上，对于减少响应大小、提高响应速度来说大有裨益;

　　提高博客性能方法三：合并CSS文件与精减CSS文件。

      和处理JavaScript文件一样，把所有的CSS文件合并到一个style.css中，CSS比 JavaScript 好处理的一点就是它冲突的机率较小，即便有冲突也不会是大问题。精简就去掉多余的样式化的格式，把所有的CSS规则都放到一行中。这款叫作Minify的 程序不但可以压缩CSS还可以压缩JavaScript和PHP程序。不过这里要提醒的是，如果你要合并和精简文件一定要保留原来的文件以便以后程序更改 时使用。 [在这里推荐一个在线更新CSS文件的地址：http://www.cleancss.com/]

　　提高博客性能方法四： 使用CSS Spirites。

       所谓的CSS Spirites就是所有CSS中用来做背景图像的图片文件都放到一个文件中。在PJBlog以及其它博客程序的皮肤中，作者很多都没有使用CSS Spirites，这样造成每出现一次background规则都要发送一次HTTP请求，而如果使用CSS Spirites则只需要一次HTTP请求，节省不必要的开支。 [说实话，这里有点痛苦，不是每个做网站的人都懂得这点，但即使懂得这点，如果改起来，对原有的CSS文件的改动也非常大，只有建议那些做模版的朋友们在做模版的时候能够考虑这点就好了。]

　　提高博客性能方法五： 使用缓存。

       对于静态内容(如Flash、 JavaScript、CSS、Image)通过加上Expires头或者Cache-Control来把它们缓存到客户端，这样用户在下次访问的时候就 可以不用下载这样内容了，这样减少了HTTP请求的次数又减少了下载文件的大小。在IIS中设置文件头很简单，在你要设置的文件或者文件夹上右键点击—— 属性——HTTP头，然后勾中“启用文件过期”，设定过期时间，可以是一年或者十年等，还可以指定某个未来的时间，如2010年等。不过你一但设置了 HTTP头，如果你要对文件作出修改你需为修改过的文件重新起一个名字。 [不知道如何在文件中设置过期时间，PHP还能通过设置头来搞定，可是CSS、JS呢？]

　　提高博客性能方法六： 启用Gzip压缩。

       Gzip压缩针对 JavaScript、CSS等内容一种压缩技术，它能大大减少文件的体积提高传输速率，精简JavaScript和CSS只是去除不必要的内容，而 Gzip压缩则是将文件在服务器端打包、在客户端解包的过程。Apache和IIS6.0都内置了Gzip技术，现代浏览器都支持Gzip技术(即使不支 持它也会告诉服务器不要打包)，因此可以放心使用。在IIS6.0中你需要简单配置之后才能使用Gzip技术，而在Apache 1.3中要启用mod_zip，在Apache 2.x使用moflate。Gzip大概可以节省70%的传输空间，目前互联网中有90%浏览器资料支持Gzip传输。

　　提高博客性能方法七： 把JavaSCript 文件放在文档的最末尾，而把CSS文件放在之间。

       CSS放在之间会加快文档下载。在Yahoo!的研 究中发现，如果你把一个CSS文件置于文档内部，当浏览器加载到这个样式表时会终止所有文件的下载而单独下载它(一般的下载浏览器使用并行下载模式)，这 是因为浏览器在下载到一个CSS文件后都要根据CSS内的规则重绘屏幕，这还会导致用户出现白屏。所以要把你所有的样式文件都放在最开始。而把 JavaScript文件放于末尾下载，一方面可以使用户首先获得文档内容，另一方面JavaScript文件的下载和其它文件不同，它不能和其它文件同 时下载，所有的JavaScript文件只有单独一个一个下载。所以在不影响使用的情况下，JavaScript文件要放在末尾加载。 [关于这点，我确实没有什么话好讲的，JS不同于其他的文件，如果网页中有JS需要在加载的时候运行，你能怎么办？说实话，如果不是用JS框架，这一点几乎不能实现，怎么可能把JS放在文件结尾呢？CSS放在之间，我想指的应该是放在head之间吧]

　　提高博客性能方法八： CSS和JavaScript文档要成为独立的外部文件。

       这是因为浏览器加载使用的是并行模式，一次可以加载多个内容，把CSS和JavaScript作为单独文件不但可以减小HTML文档的大小，而可以加快下载效率。 [关于这点，在yslow的介绍文件里也有说明，意思是如果有可能，请尽量为你的CSS中的图片和JS使用单独的域名，这样，即使出现404，也不会影响当前页面的下载，可以加快浏览速度，而且放到单独的域名里之后，也可以更方便的使用、设置过期时间什么的]

　　提高博客性能方法九： 使用少量的域名。

      一般来说一个页面引用的文件(图片、Flash、CSS、JavaScript)不能多于四个主机，因为每多出一个域名就意味着多一个 DNS的查找，在浏览器查找DNS信息的过程中，浏览器由于不知道要访问的IP地址是什么，所以它什么都不做，只是在等待，所以DNS查找的次数越少，响 应速度就越快。 [这一点，我在yslow里面看到了，同样说明，如果我们要放广告的话，尽量使用同一个网站的广告，这样也能避免DNS查找花费太大的时间]

　　提高博客性能方法十： 避免CSS中使用Expression。

      虽然功能很强大，但是它的计算频率太高，影响网站的整体性能。对于一个CSS Expression来说，即使你滚动一下屏幕它都要重新计算一次，甚至你移到一次鼠标它都要重新计算，所有一个CSS Express在页面中计算10000次是很容易的事情。 

       以上就如何提高博客性能方法提出的十条建议。

说的虽然是提高博客性能，但几乎对每个网站的优化都有一定的好处。如果需要更详细的介绍，我想，应该是看那篇关于网页设计的14条军规（现在改为20条了），也可以通过yslow来进行检测，看看你的网站被打分多少。yslow的检测是根据以前的14条军规而进行检测的，现在还没有更新的20条。
所谓的军规也是yahoo那帮子人提出来的，现在也成为了一种规范，yslow就是在这个基础上进行开发，不过yslow是FF的插件哦，IE下面有httpwatch插件，可以清楚的看到网站的每一个页面加载花费了多少时间，在哪个文件或者图片上所花费的时间最长，那么就可以有针对性的进行更新了。