Ratproxy — Google 的 XSS 检测工具

跨站脚本攻击(XSS, Cross Site Scripting) 可能是目前所有网站都比较头疼的问题，Google 也不例外。这次 Google 又做了一次雷锋，把内部用来审计 XSS 的工具开源了：ratproxy。

Google_ratProxy.png
Ratproxy 工作流程：

  • 1) 运行脚本后，会在本地启动一个代理服务器，默认端口是 8080 ；
  • 2) 浏览器设置这个地址 (http://localhost:8080)为 代理地址 ；
  • 3) 浏览要测试的 Web 页面，进行实际登录，填写表单等操作(这些动作会被代理服务器捕捉并做点”手脚”发给待检测的页面)，ratproxy 会在后台记录相关的 Log ；
  • 4) 用 ratproxy 提供的工具解析 Log 并输出 HTML 进行分析；
  • 5) 修正比较严重的问题后，跳回到第一步，直到评估通过为止。

在我的 Ubuntu 下测试了一下，需要说一下的是，本地系统需要安装 libssl-dev 与 openssl 。

$ sudo apt-get install libssl-dev openssl 
$ cd ratproxy ;  make

然后就可以提交类似:

$ ./ratproxy -v . -w foo.log -d foo.com -lfscm

然后，人肉点击相关的页面进行测试了。这个工具的设计思路还是很值得借鉴的，推荐对安全感兴趣的同学读一下源代码。

ratproxy 的作者是 MIchal Zalewski，一个波兰的白帽子黑客。他的个人主页上能找到更多有趣的工具。

–EOF–

另参见另一份试用报告

Updated：Google的另一个工具：Skipfish 尤其值得关注。

Jiffy — 端到端的 Web 性能评测框架

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。

而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似”望闻问切”的诊断方式，那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制：
Jiffy.png

通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不久就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。

–EOF–

更新：有得朋友说，安装了，点击了，没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。

BASE — 高可用架构的基石之一

在讨论 eBay 的Scalability最佳实践 的时候，结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然，我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：

  • Basically Available –基本可用
  • Soft-state –软状态/柔性事务
  • Eventual Consistency –最终一致性

“Soft state” (SS) 是与 “Hard state”(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的，这样就清晰多了。

最终一致性， 也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。

BTW: “ACID” 英文里面有”酸”的意思，而 “BASE” 有”碱”的意思. 酸碱在一起才能中和啊，哈

–EOF–

Web 前端优化最佳实践之 Mobile(iPhone) 篇

Web 前端优化最佳实践最后一部分是针对移动应用的，其实只是针对 iPhone 的，目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M，但经过测试，发现也就是 25K 左右。

iPhone 在市场上的优异表现，让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详，等待后续更新吧。

–EOF–

Updated: 根据这篇 iPhone caching 的文章，可供 Cache 的最大单个数据对象是 15K，而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。