>

原则：

1.2.1. 深度防范

深度防范原则是安全专业人员人人皆知的原则，它说明了冗余安全措施的价值，这是被历史所证明的。

深度防范原则可以延伸到其它领域，不仅仅是局限于编程领域。使用过备份伞的跳伞队员可以证明有冗余安全措施是多么的有价值,尽管大家永远不希望主伞失效。一个冗余的安全措施可以在主安全措施失效的潜在的起到重大作用。

回到编程领域，坚持深度防范原则要求您时刻有一个备份方案。如果一个安全措施失效了，必须有另外一个提供一些保护。例如，在用户进行重要操作前进行重新用户认证就是一个很好的习惯，尽管你的用户认证逻辑里面没有已知缺陷。如果一个未认证用户通过某种方法伪装成另一个用户，提示录入密码可以潜在地避免未认证(未验证)用户进行一些关键操作。

尽管深度防范是一个合理的原则，但是过度地增加安全措施只能增加成本和降低价值。

1.2.2. 最小权限

我过去有一辆汽车有一个佣人钥匙。这个钥匙只能用来点火，所以它不能打开车门、控制台、后备箱，它只能用来启动汽车。我可以把它给泊车员(或把它留在点火器上)，我确认这个钥匙不能用于其它目的。

把一个不能打开控制台或后备箱的钥匙给泊车员是有道理的，毕竟，你可能想在这些地方保存贵重物品。但我觉得没有道理的是为什么它不能开车门。当然，这是因为我的观点是在于权限的收回。我是在想为什么泊车员被取消了开车门的权限。在编程中，这是一个很不好的观点。相反地，你应该考虑什么权限是必须的，只能给予每个人完成他本职工作所必须的尽量少的权限。

一个为什么佣人钥匙不能打开车门的理由是这个钥匙可以被复制，而这个复制的钥匙在将来可能被用于偷车。这个情况听起来不太可能发生，但这个例子说明了不必要的授权会加大你的风险，即使是增加了很小权限也会如此。风险最小化是安全程序开发的主要组成部分。

你无需去考虑一项权限被滥用的所有方法。事实上，你要预测每一个潜在攻击者的动作是几乎不可能的。

1.2.3. 简单就是美

复杂滋生错误，错误能导致安全漏洞。这个简单的事实说明了为什么简单对于一个安全的应用来说是多么重要。没有必要的复杂与没有必要的风险一样糟糕。

例如，下面的代码摘自一个最近的安全漏洞通告：

这个流程会混淆$search变量受污染*的事实，特别是对于缺乏经验的开发者而言。上面语句等价于下面的程序：

上面的两个处理流程是完全相同的。现在请注意一下下面的语句:

$search = $_GET['search'];

使用这一语句，在不影响流程的情况下，保证了$search变量的状态维持原样，同时还可以看出它是否受污染。

* 译注：受污染变量，即在程序执行过程中，该变量的值不是由赋值语句直接指定值，而是来自其它来源，如控制台录入、数据库等。

1.2.4. 暴露最小化

PHP应用程序需要在PHP与外部数据源间进行频繁通信。主要的外部数据源是客户端浏览器和数据库。如果你正确的跟踪数据，你可以确定哪些数据被暴露了。Internet是最主要的暴露源，这是因为它是一个非常公共的网络，您必须时刻小心防止数据被暴露在Internet上。

数据暴露不一定就意味着安全风险。可是数据暴露必须尽量最小化。例如，一个用户进入支付系统，在向你的服务器传输他的信用卡数据时，你应该用SSL去保护它。如果你想要在一个确认页面上显示他的信用卡号时，由于该卡号信息是由服务器发向他的客户端的，你同样要用SSL去保护它。

再谈谈上一小节的例子，显示信用卡号显然增加了暴露的机率。SSL确实可以降低风险，但是最佳的解决方案是通过只显示最后四位数，从而达到彻底杜绝风险的目的。

为了降低对敏感数据的暴露率，你必须确认什么数据是敏感的，同时跟踪它，并消除所有不必要的数据暴露。在本书中，我会展示一些技巧，用以帮助你实现对很多常见敏感数据的保护。

方法：

1.3.1. 平衡风险与可用性

用户操作的友好性与安全措施是一对矛盾，在提高安全性的同时，通常会降低可用性。在你为不合逻辑的使用者写代码时，必须要考虑到符合逻辑的正常使用者。要达到适当的平衡的确很难，但是你必须去做好它，没有人能替代你，因为这是你的软件。

尽量使安全措施对用户透明，使他们感受不到它的存在。如果实在不可能，就尽量采用用户比较常见和熟悉的方式来进行。例如，在用户访问受控信息或服务前让他们输入用户名和密码就是一种比较好的方式。

当你怀疑可能有非法操作时，必须意识到你可能会搞借。例如，在用户操作时如果系统对用户身份有疑问时，通常用让用户再次录入密码。这对于合法用户来说只是稍有不便，而对于攻击者来说则是铜墙铁壁。从技术上来说，这与提示用户进行重新登录基本是一样的，但是在用户感受上，则有天壤之别。

没有必要将用户踢出系统并指责他们是所谓的攻击者。当你犯错时，这些流程会极大的降低系统的可用性，而错误是难免的。

在本书中，我着重介绍透明和常用的安全措施，同时我建议大家对疑似攻击行为做出小心和明智的反应。

1.3.2. 跟踪数据

作为一个有安全意识的开发者，最重要的一件事就是随时跟踪数据。不只是要知道它是什么和它在哪里，还要知道它从哪里来，要到哪里去。有时候要做到这些是困难的，特别是当你对WEB的运做原理没有深入理解时。这也就是为什么尽管有些开发者在其它开发环境中很有经验，但他对WEB不是很有经验时，经常会犯错并制造安全漏洞。

大多数人在读取EMAIL时，一般不会被题为"Re: Hello"之类的垃圾邮件所欺骗，因为他们知道，这个看起来像回复的主题是能被伪造的。因此，这封邮件不一定是对前一封主题为"Hello."的邮件的回复。简而言之，人们知道不能对这个主题不能太信任。但是很少有人意识到发件人地址也能被伪造，他们错误地认为它能可靠地显示这个EMAIL的来源。

Web也非常类似，我想教给大家的其中一点是如何区分可信的和不可信的数据。做到这一点常常是不容易的，盲目的猜测并不是办法。

PHP通过超级全局数组如$_GET, $_POST, 及$_COOKIE清楚地表示了用户数据的来源。一个严格的命名体系能保证你在程序代码的任何部分知道所有数据的来源，这也是我一直所示范和强调的。

知道数据在哪里进入你的程序是极为重要的，同时知道数据在哪里离开你的程序也很重要。例如，当你使用echo指令时，你是在向客户端发送数据;当你使用mysql_query时，你是在向MySQL数据库发送数据(尽管你的目的可能是取数据)。

在我审核PHP代码是否有安全漏洞时，我主要检查代码中与外部系统交互的部分。这部分代码很有可能包含安全漏洞，因此，在开发与代码检查时必须要加以特别仔细的注意。

1.3.3. 过滤输入

过滤是Web应用安全的基础。它是你验证数据合法性的过程。通过在输入时确认对所有的数据进行过滤，你可以避免被污染(未过滤)数据在你的程序中被误信及误用。大多数流行的PHP应用的漏洞最终都是因为没有对输入进行恰当过滤造成的。

我所指的过滤输入是指三个不同的步骤：

l 识别输入

l 过滤输入

l 区分已过滤及被污染数据

把识别输入做为第一步是因为如果你不知道它是什么，你也就不能正确地过滤它。输入是指所有源自外部的数据。例如，所有发自客户端的是输入，但客户端并不是唯一的外部数据源，其它如数据库和RSS推送等也是外部数据源。

由用户输入的数据非常容易识别，PHP用两个超级公用数组$_GET 和$_POST来存放用户输入数据。其它的输入要难识别得多，例如，$_SERVER数组中的很多元素是由客户端所操纵的。常常很难确认$_SERVER 数组中的哪些元素组成了输入，所以，最好的方法是把整个数组看成输入。

在某些情况下，你把什么作为输入取决于你的观点。例如，session数据被保存在服务器上，你可能不会认为session数据是一个外部数据源。如果你持这种观点的话，可以把session数据的保存位置是在你的软件的内部。意识到session的保存位置的安全与软件的安全是联系在一起的事实是非常明智的。同样的观点可以推及到数据库，你也可以把它看成你软件的一部分。

一般来说，把session保存位置与数据库看成是输入是更为安全的，同时这也是我在所有重要的PHP应用开发中所推荐的方法。

一旦识别了输入，你就可以过滤它了。过滤是一个有点正式的术语，它在平时表述中有很多同义词，如验证、清洁及净化。尽管这些大家平时所用的术语稍有不同，但它们都是指的同一个处理：防止非法数据进入你的应用。

有很多种方法过滤数据，其中有一些安全性较高。最好的方法是把过滤看成是一个检查的过程。请不要试图好心地去纠正非法数据，要让你的用户按你的规则去做，历史证明了试图纠正非法数据往往会导致安全漏洞。例如，考虑一下下面的试图防止目录跨越的方法(访问上层目录)。

CODE:

$filename = str_replace('..', '.', $_POST['filename']);

?>

你能想到$_POST['filename']如何取值以使$filename成为Linux系统中用户口令文件的路径../../etc/passwd吗?

答案很简单：

.../.../etc/passwd

这个特定的错误可以通过反复替换直至找不到为止：

当然，函数basename( )可以替代上面的所有逻辑，同时也能更安全地达到目的。不过重要点是在于任何试图纠正非法数据的举动都可能导致潜在错误并允许非法数据通过。只做检查是一个更安全的选择。