最近写一点东西需要解析HTML，本来想以python的强大，简洁的语法应该很好用，结果在解析HTML的时候，尝试了好几个官方的库，都非常的矬，无法满足我的需求。 最后无奈，只好改用JS实现，对于HTML的理解，还是浏览器最方便啊。 看来Python 作为新兴语言，第三方资源的积累还是不如老语言丰富，还有很长的路要走啊。 以后有时间还是自己写个HTML

百度的图片和很多网站防盗链措施一样，是基于Referer 判断的 1. 如果浏览器发送的Referer 中不是从百度的域过来的，则判断为盗链 2. 如果浏览器没有发送Referer 头，则认为是不是盗链 现在网上的很多教程都教人怎么伪造Referer，或者不发送Referer。比如Firefox在 about:config 中，可以有选项把Referer的发送给关闭掉。也有很多浏览器的插件和扩展，可以改掉Referer，比较出名的有 RefControl 等。 除此之外

参考阅读： http://queue.acm.org/detail.cfm?id=1556050 这个架构和 Gazelle 很像啊! 不过做的没有 Gazelle 严格，当然 Gazelle 还只是实验室的东西。 G

这几天圈内关于 Slowloris 的讨论比较多，原因是 RSnake 的一篇文章 http://ha.ckers.org/blog/20090617/slowloris-http-dos/ Sowhat 也写了点评论 http://hi.baidu.com/secway/blog/item/c7aca3a28f9521a4cbefd0e2.html 这种攻击是很古老的攻击了，apache的连接数有限（并发），配置文件里可以更改，

Fuzz分很多种，有大的是fuzz整个应用，有小的是fuzz个别函数。有的是fuzz 网络协议，有的则是fuzz某个接口。 但总的来说，FUZZ都是填充脏数据，然后捕获异常，最后发现问题的一个过程。 所以，FUZZ有三个关键 1. 如何填充脏数据 2. 如何捕获异常 3. 获取异常后如何回溯执行过程 FUZZ可以算作是黑箱测试的一种，输入提供脏数据，黑箱里经过复杂逻辑运算后，如果输出异常，则开始回溯整个过程。 对于WEB 应用来说，同样也是这个过程。 虽然WEB应用可以分

前段时间写了篇HTTPS与代理的问题，其实当天还有篇关于HTTPS的我没写，是另外一个人提到的，在现在的某些https的服务器上往往能够降低加密级别进行传输。 我做了以下测试： #openssl s_client -connect www.test.com:443 -cipher LOW

今天推荐阅读的 Pretty-Bad-Proxy: An Overlooked Adversary in Browsers’ HTTPS Deployments 这篇paper应该是微软研究院的几个中国人搞出来的。 我们知道在不使用中间人攻击的情况下（伪造证书），HTTPS还是比较安全的。（sslv3 防范了中间人攻击） 但是，恶意代理即使无法直接读到HTTPS加密过后的明

关于bing的一些安全讨论 The Security of Bing 安全需求的一些对比参考 Weak and Strong Web Security Requirements SAMM，一个开放的软件安全开发的框架，感觉写的非常好

微软酝酿已久的搜索引擎终于出炉了，叫做：bing 一看这个域名，就知道微软确实是下了功夫的。 最近也正在给自己开发的网站选择域名，所以对域名有了点研究 在域名选择上，我们一般会注意这么几点： 1. 不能太复杂，太长 类似 searchengineland.com 这种域名，就属于太长了，一眼望过去，会眼花。 同样的，microsoft.com ，也属于比较长的域名。 2. 如果选择单词做域名，一定要选择最常见的单词 比如 ok.

只是管中窥豹，因为google没有公开什么安全方面的文档，我也没有深入研究和测试GAE对各项攻击的防范，只是作为一个google的用户简单讲讲。 首先，底层肯定是构建在GFS上，使用分布式存储，存储所有的数据，也就是google 的云存储。 往上，可能就是计算平台，包括任务调度、SQL 引擎， Key-Value 引擎的。 App Engine 构架于这些基础服务之上，对外提供服务。 Sandbox: GAE目前支持 java 和 python 代码的运行，两者都是有sandbox的（java 用 securitymanager）。通过 sandbox 的

Google 有意思的东西真的非常多，比如这个 Native Client 不知道这个东西在Google 产品线里是一个什么地位，是否处在一个战略位置上，还是说仅仅是弄一个出来玩玩的。 简单说，就是一个类似 ActiveX 的东西，能够直接在浏览器中调用Native Client执行二进制代码。 但是微软的 ActiveX 曾经被评为是微软最错误的设计，所以 Google Native Client 的一个想法就是把这种设计变安全。 ActiveX 能够直接和OS进行通信，直接在OS上

据harry的小道消息说，他几个月前就看到这篇paper了。#_# 黑哥前几天拿到了，给我们看了下，确实挺有意思，也可以算作是一种新的攻击类型。 因为今天wisec（作者）的演讲已经出来了，所以就可以在blog上写写了。 以下摘自作者blog：http://www.wisec.it/sectou.php?id=4a129d3c810ec On May 14th @ 2009OWASP Appsec Poland, me &

这句话在我写的 webzine0x03 的paper 中只出现了一次，但是却是一条非常重要的原则，其重要程度甚至可以作为最佳实践3 放在paper中。 为什么提“在正确的地方做正确的事情”？ 从XSS 防御的发展历史来看，可以很好的体现这一点。 我曾经画了一张图，来表示这个过程

这个认知也是我前段时间总结的，本来也可以以此为题写篇paper，但出于惰性搁置了。 如果想用英文装bi，可以这么写： The requirement itself has no fault, the problem is whether the implementation is secure enough. 我认为需求是应该要尽量满足的，不应该说需求错了，有需求就有合理性。 问题往往出在需求的实现上，实现是会出错的，有可能会存在安全问题。

十个月！ 虽然难产，不过还是生下来了！ 这期的内容以web为主，篇篇都非常精彩！！ 茄子一如既往的放0day，80vul写了篇堪称集PHP安全之大成的paper 我也写了篇WEB安全的设计思想，是根据去腾讯峰会的演讲总结而成，可以对比下这