前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。
Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。
最近一两年，DDoS 攻击在国内现在更加”流行”而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的…
其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。
–EOF–
BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行…必备…
关于支付宝的证书使用中出现的 800A138F 错误是个老问题了。这里尝试对这个问题做说说个人看法。
历史原因说来话长，我尽量说得简要一些。首先需要涉及证书（Certificate ）在操作系统中通过 ActiveX 形式的登记（Enrollment ）这事儿。在 Windows XP 之前，延续使用的是 XEnroll.dll 这个库接口。但是因为这东西比较古老，且出于”更安全”、更方便开发的角度上考虑，从 Windows Vista 与 Windows Server 2008 开始引入 CertEnroll.dll （参考)。这个差异也导致了支付宝证书在不同版本的操作系统间的导出再导入可能会出现问题。
一般来说，错误信息类似如下：
错误原因：'cenroll' 为空或不是对象，错误代码：800A138F。
Microsoft XEnroll，在产生密钥对时失败！错误原因：'null'为空或不是对象，错误编码：800A138F
(这个错误信息表明是使用 XEnroll.dll 过程中出现了问题。)
不知出于什么考虑，微软上 Vista 的时候居然没考虑到 XEnroll.dll 这东西没了，向后兼容性如何处理呢? 而有些第三方开发厂商也不是未卜先知。所以，Vista 大量涌入市场的时候就暴露出来了问题(当然第三方开发商也要狠狠的打自己自己一个嘴巴)。微软的拿手解决方案就是发行一个补丁 ，在 Vista 和 Windows Server 2008 上也能使用老的 “Certificate Services Web enrollment pages” （其实就是给 操作系统里安装一个 XEnroll.dll 库)。参见知识库 922706 。
这个 800A138F 错误大多数时候出现在 Vista 系统上。也是有很多其他客观因素的，其中比较主要的一个是 User Account Control(UAC)这个特性带来的麻烦。UAC 默认级别替用户”多考虑许多”，安全级别控制的很好，好到这个安全成了麻烦。这个如果通过系统管理员用户一项一项的去设置的话，是可以对付安装上的，但是不可避免的是，很多用户不是操作系统专家，甚至不知道什么是”系统管理员”，所以如果把 UAC 关闭的话，可能会直接省了不少麻烦，但是这样的话，又有很多用户会觉得安全性受到了威胁，也难免抓狂，这个选择很是两难。
除了 Vista ，在 XP 上也会遇到这个错误。一般来说，某些第三方的小工具会禁止 Microsoft Certificate Enrollment CAB (这也是非常头疼的一个问题)，这种情况下可以考虑修改注册表或者是在这类工具的插件管理的地方把这个 CAB 放开。或者考虑修改注册表的方式 (参考)。
我的个人建议是：不要使用 Windows Vista ！(请默念10遍：Windows Vista 是个烂系统) 这是个微软内部都承认失败的操作系统。使用老的 Windows XP 吧，毕竟，微软已经承诺对 XP 延续支持到 2011 年了。至于 Windows 7 ，尽管叫好声不断，但我们现在只能期待。
另外，对于 IE 用户，建议使用 IE7 或者 IE8 (IE6 出来已经有 10 年，老掉牙矣，且从安全性的角度上考虑也的确不佳)。
以上是对支付宝证书错误 800A138F 的一点非专业解释，兄弟我并非 Windows 操作系统专家，期待对 Windows 操作系统更为熟悉的朋友进行补充以及纠正。现在情况已经如此，一刀切解决问题似乎不太现实，没有理由推卸任何责任(尽管个别读者可能这么认为)，只能尽量、尽快改进–现在已经在和合作方一起进行对此错误的处理！
用户的痛苦我也是感同身受！这并非客套话。
–EOF–
注意：这篇文章有实效性，且包括作者本人主观看法。
更新：从用户的反馈来看，Windows 7 比 Vista 易用性和性能好了很多，推荐使用。
且说我使用有些网络服务的时候常常能遇到比较怪异的问题。昨天在某个页面遇到个 Redirect Loop 错误提示：
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
同样的问题，同样的页面，同样是 Firefox 浏览器，以前就遇到过，提交给相关负责人之后没了响应，后来也忘掉了。同事说是我浏览器版本的问题，后来发现这和”是否接受第三方 Cookie” 的设置有关：
[x] Accept cookies from sites [ ] Accept third-party cookies
我的浏览器不接受第三方 Cookie。设置接收后该页面显示正常。
搜索了一下，发现之所以该页面是这样，还是因为页面用了 iframe 而导致的问题，比较通用的办法是设置 p3p http header 。
这个 P3P(Platform for Privacy Preferences Project)，要搞明白，可真是有点小孩没娘，说来话长。简单的说，就是个协议，通过其声明它是好人，允许我收集浏览器用户行为吧… 可现实中，大家都可以说自己是好人，背地里没准儿干啥坏事呢。这就是其分歧所在。[参考] 国内多数网站，都不关注这个 P3P。隐私问题可能没国外(微软的隐私声明)重视吧。
再说 Firefox ，过去的几个大版本中，对 Cookie 的处理方式还是有很大变化的。
这个问题影响最大的还是 Facebook 等开放平台的应用，使用了 iframe 就会遇到(eg: FriendFeed 遇到过，估计还比较头疼)。
对于浏览器来说，第三方 Cookie ，默认情况下，浏览器接受与否，是个大问题。如果不接受，会给很多用户带来混淆，如果接受，则在隐私问题上，有很大的挑战。
实际上，Firefox 的开发者在这个地方的处理方式也在摇摆当中(参见), 不过能确定的是 “the ability to make decisions based on p3p policies was removed for firefox 3″。
各家浏览器在这个地方都可能有 Bug。比如 IE7 曾经有的 Cookie 问题，IE8 Beta 也有类似问题。
或许，最好的办法就是别去种这个 Cookie 了… 网站开发者，你们愿意么?
–EOF–
更多阅读：Windows Internet Explorer (Pre-Release Version 8) Privacy Statement
微软 Cookie 说明
另请参见文本后面 axis 同学的留言。
跨站脚本攻击(XSS, Cross Site Scripting) 可能是目前所有网站都比较头疼的问题，Google 也不例外。这次 Google 又做了一次雷锋，把内部用来审计 XSS 的工具开源了：ratproxy。
Ratproxy 工作流程：
在我的 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 尤其值得关注。