原则：
1.2.1. 深度防范
深度防范原则是安全专业人员人人皆知的原则，它说明了冗余安全措施的价值，这是被历史所证明的。
深度防范原则可以延伸到其它领域，不仅仅是局限于编程领域。使用过备份伞的跳伞队员可以证明有冗余安全措施是多么的有价值,尽管大家永远不希望主伞失效。一个冗余的安全措施可以在主安全措施失效的潜在的起到重大作用。
回到编程领域，坚持深度防范原则要求您时刻有一个备份方案。如果一个安全措施失效了，必须有另外一个提供一些保护。例如，在用户进行重要操作前进行重新用户认证就是一个很好的习惯，尽管你的用户认证逻辑里面没有已知缺陷。如果一个未认证用户通过某种方法伪装成另一个用户，提示录入密码可以潜在地避免未认证（未验证）用户进行一些关键操作。
尽管深度防范是一个合理的原则，但是过度地增加安全措施只能增加成本和降低价值。
1.2.2. 最小权限
我过去有一辆汽车有一个佣人钥匙。这个钥匙只能用来点火，所以它不能打开车门、控制台、后备箱，它只能用来启动汽车。我可以把它给泊车员（或把它留在点火器上），我确认这个钥匙不能用于其它目的。
把一个不能打开控制台或后备箱的钥匙给泊车员是有道理的，毕竟，你可能想在这些地方保存贵重物品。但我觉得没有道理的是为什么它不能开车门。当然，这是因为我的观点是在于权限的收回。我是在想为什么泊车员被取消了开车门的权限。在编程中，这是一个很不好的观点。相反地，你应该考虑什么权限是必须的，只能给予每个人完成他本职工作所必须的尽量少的权限。
一个为什么佣人钥匙不能打开车门的理由是这个钥匙可以被复制，而这个复制的钥匙在将来可能被用于偷车。这个情况听起来不太可能发生，但这个例子说明了不必要的授权会加大你的风险，即使是增加了很小权限也会如此。风险最小化是安全程序开发的主要组成部分。
你无需去考虑一项权限被滥用的所有方法。事实上，你要预测每一个潜在攻击者的动作是几乎不可能的。
1.2.3. 简单就是美
复杂滋生错误，错误能导致安全漏洞。这个简单的事实说明了为什么简单对于一个安全的应用来说是多么重要。没有必要的复杂与没有必要的风险一样糟糕。
例如，下面的代码摘自一个最近的安全漏洞通告：
CODE:
<?php
$search = (isset($_GET['search']) ? $_GET['search'] : '');
?>
这个流程会混淆$search变量受污染*的事实，特别是对于缺乏经验的开发者而言。上面语句等价于下面的程序：
CODE:
<?php
$search = '';
if (isset($_GET['search'])){
$search = $_GET['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:
<?php
$filename = str_replace('..', '.', $_POST['filename']);
?>
你能想到$_POST['filename']如何取值以使$filename成为Linux系统中用户口令文件的路径../../etc/passwd吗？
答案很简单：
.../.../etc/passwd
这个特定的错误可以通过反复替换直至找不到为止：
CODE:
<?php
$filename = $_POST['filename'];
while (strpos($_POST['filename'], '..') != = FALSE){
$filename = str_replace('..', '.', $filename);
}
?>
当然，函数basename( )可以替代上面的所有逻辑，同时也能更安全地达到目的。不过重要点是在于任何试图纠正非法数据的举动都可能导致潜在错误并允许非法数据通过。只做检查是一个更安全的选择。
译注：这一点深有体会，在实际项目曾经遇到过这样一件事，是对一个用户注册和登录系统进行更改，客户希望用户名前后有空格就不能登录，结果修改时对用户登录程序进行了更改，用trim（）函数把输入的用户名前后的空格去掉了（典型的好心办坏事），但是在注册时居然还是允许前后有空格！结果可想而知。
除了把过滤做为一个检查过程之外，你还可以在可能时用白名单方法。它是指你需要假定你正在检查的数据是非法的，除非你能证明它是合法的。换而言之，你宁可在小心上犯错。使用这个方法，一个错误只会导致你把合法的数据当成是非法的。尽管不想犯任何错误，但这样总比把非法数据当成合法数据要安全得多。通过减轻犯错引起的损失，你可以提高你的应用的安全性。尽管这个想法在理论上是很自然的，但历史证明，这是一个很有价值的方法。
如果你能正确可靠地识别和过滤输入，你的工作就基本完成了。最后一步是使用一个命名约定或其它可以帮助你正确和可靠地区分已过滤和被污染数据的方法。我推荐一个比较简单的命名约定，因为它可以同时用在面向过程和面向对象的编程中。我用的命名约定是把所有经过滤的数据放入一个叫$clean的数据中。你需要用两个重要的步骤来防止被污染数据的注入：
l 经常初始化$clean为一个空数组。
l 加入检查及阻止来自外部数据源的变量命名为clean，
实际上，只有初始化是至关紧要的，但是养成这样一个习惯也是很好的：把所有命名为clean的变量认为是你的已过滤数据数组。这一步骤合理地保证了$clean中只包括你有意保存进去的数据，你所要负责的只是不在$clean存在被污染数据。
为了巩固这些概念，考虑下面的表单，它允许用户选择三种颜色中的一种；
CODE:
<form action="process.php" method="POST">
Please select a color:
<select name="color">
<option value="red">red</option>
<option value="green">green</option>
<option value="blue">blue</option>
</select>
<input type="submit" />
</form>
在处理这个表单的编程逻辑中，非常容易犯的错误是认为只能提交三个选择中的一个。在第二章中你将学到，客户端能提交任何数据作为$_POST['color']的值。为了正确地过滤数据，你需要用一个switch语句来进行：
CODE:
<?php
$clean = array( );
switch($_POST['color']) {
case 'red':
case 'green':
case 'blue':
$clean['color'] = $_POST['color'];
break;
}
?>
本例中首先初始化了$clean为空数组以防止包含被污染的数据。一旦证明$_POST['color']是red, green, 或blue中的一个时，就会保存到$clean['color']变量中。因此，可以确信$clean['color']变量是合法的，从而在代码的其它部分使用它。当然，你还可以在switch结构中加入一个default分支以处理非法数据的情况。一种可能是再次显示表单并提示错误。特别小心不要试图为了友好而输出被污染的数据。
上面的方法对于过滤有一组已知的合法值的数据很有效，但是对于过滤有一组已知合法字符组成的数据时就没有什么帮助。例如，你可能需要一个用户名只能由字母及数字组成：
CODE:
<?php
$clean = array( );
if (ctype_alnum($_POST['username'])) {
$clean['username'] = $_POST['username'];
}
?>
尽管在这种情况下可以用正则表达式，但使用PHP内置函数是更完美的。这些函数包含错误的可能性要比你自已写的代码出错的可能性要低得多，而且在过滤逻辑中的一个错误几乎就意味着一个安全漏洞。
1.3.4. 输出转义
另外一个Web应用安全的基础是对输出进行转义或对特殊字符进行编码，以保证原意不变。例如，O'Reilly在传送给MySQL数据库前需要转义成O\'Reilly。单引号前的反斜杠代表单引号是数据本身的一部分，而不是并不是它的本义。
我所指的输出转义具体分为三步：
l 识别输出
l 输出转义
l 区分已转义与未转义数据
只对已过滤数据进行转义是很有必要的。尽管转义能防止很多常见安全漏洞，但它不能替代输入过滤。被污染数据必须首先过滤然后转义。
在对输出进行转义时，你必须先识别输出。通常，这要比识别输入简单得多，因为它依赖于你所进行的动作。例如，识别到客户端的输出时，你可以在代码中查找下列语句：
echo
printf
<?=
作为一项应用的开发者，你必须知道每一个向外部系统输出的地方。它们构成了输出。
象过滤一样，转义过程在依情形的不同而不同。过滤对于不同类型的数据处理方法也是不同的，转义也是根据你传输信息到不同的系统而采用不同的方法。
对于一些常见的输出目标（包括客户端、数据库和URL）的转义，PHP中有内置函数可用。如果你要写一个自己算法，做到万无一失很重要。需要找到在外系统中特殊字符的可靠和完整的列表，以及它们的表示方式，这样数据是被保留下来而不是转译了。
最常见的输出目标是客户机，使用htmlentities( )在数据发出前进行转义是最好的方法。与其它字符串函数一样，它输入是一个字符串，对其进行加工后进行输出。但是使用htmlentities( )函数的最佳方式是指定它的两个可选参数：引号的转义方式（第二参数）及字符集（第三参数）。引号的转义方式应该指定为ENT_QUOTES，它的目的是同时转义单引号和双引号，这样做是最彻底的，字符集参数必须与该页面所使用的字符集相必配。
为了区分数据是否已转义，我还是建议定义一个命名机制。对于输出到客户机的转义数据，我使用$html数组进行存储，该数据首先初始化成一个空数组，对所有已过滤和已转义数据进行保存。
CODE:
<?php
$html = array( );
$html['username'] = htmlentities($clean['username'], ENT_QUOTES, 'UTF-8');
echo "<p>Welcome back, {$html['username']}.</p>";
?>
小提示
htmlspecialchars( )函数与htmlentities( )函数基本相同，它们的参数定义完全相同，只不过是htmlentities( )的转义更为彻底。
通过$html['username']把username输出到客户端，你就可以确保其中的特殊字符不会被浏览器所错误解释。如果username只包含字母和数字的话，实际上转义是没有必要的，但是这体现了深度防范的原则。转义任何的输出是一个非常好的习惯，它可以戏剧性地提高你的软件的安全性。
另外一个常见的输出目标是数据库。如果可能的话，你需要对SQL语句中的数据使用PHP内建函数进行转义。对于MySQL用户，最好的转义函数是 mysql_real_escape_string( )。如果你使用的数据库没有PHP内建转义函数可用的话，addslashes( )是最后的选择。
下面的例子说明了对于MySQL数据库的正确的转义技巧：
CODE:
<?php
$mysql = array( );
$mysql['username'] = mysql_real_escape_string($clean['username']);
$sql = "SELECT *
FROM profile
WHERE username = '{$mysql['username']}'";
$result = mysql_query($sql);
?>
