Blacklist杂谈

今天准备炮轰Blacklist。

做安全的大多知道黑名单和白名单两种思想，也知道白名单会比黑名单更安全。

最近的两个例子正好再次说明了这一点.

首先是前两天HD Moore在blog上提到的PHP safe mode的问题。

PHP Safe Mode 如果开启的话，会禁止一系列的有“危害”的PHP函数的执行，是一个黑名单的机制，类似被禁止的函数有 system()、passthru() 等很多。官方的思路是希望在“共享”环境下解决一些安全问题，对黑客来说，如果safemode开启，一些函数被禁止，PHP Webshell就更难写了。

但是一直以来，我们看到了层出不穷的PHP Bypass Safe Mode 的方法

PHP的开发者近日也承认，尝试在PHP层面用Safe Mode解决这个问题是不太靠谱的，因为很多东西都和系统关系太紧密了。一些模块的函数可能导致从系统层面绕过Safe Mode.

而Safe Mode 使用的黑名单机制，导致只要有一个bug，整个安全机制就会完全失效。

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now. 

所以，在PHP 6.0.0 里，已经移除了 Safe Mode


此外今天黑哥在群里又推荐了篇blog，提到urlscan最近更新了，因为作者发现了一种绕过urlscan的方法

就是在SQL 语法中插入 %

%后面如果跟正确的16进制数，会被ASP正确的decode，如果后面跟的不是，则会丢弃掉%。

ASP drops a percent sign from the query string if it isn't followed by two valid hex characters(0-9, A-F) when it actually interprets it via Request.QueryString. This means that any filter that inspects raw headers using Request.ServerVariables is going to miss "DEC%LARE" if it is looking for "DECLARE" but, on the other hand, the ASP app that actually consumes that string using Request.QueryString("abc") is going to get it without the percent sign.

这个特性就导致了攻击者使用 DEC%LARE 这种方式来绕过一些 filter ，但是在ASP程序里又会去掉%。 这也是一个系统层级之间对数据理解的差异性导致的安全问题，类似字符集漏洞。

又是一个bug就绕过了黑名单！所以urlscan更新了。

基于黑名单的安全应用会把黑名单变的越来越长，因为需要考虑到越来越多的情况。长的黑名单更容易影响到性能。

由此看来，黑名单，是一块典型的鸡肋。

比较好的做法是一开始就使用白名单机制，规范好数据，甚至是把数据拆分到元数据，在展示时候再次进行组装。

白名单需要担心的一个问题就是对用户的行为规定太死，可能会影响到用户的正常需求。如果白名单可以随意扩充，则会越写越长，到最后大家都在白名单里，出现了万恶的通配符 *，惨剧也就会随之而来。

所以好的安全设计，一定要做到 secure by default, 在开始，就做好最坏的打算，尽量用好白名单，不要用黑名单，免得以后改起来还伤筋动骨。