首先是文本格式转换方面的有效函数，以前的文章我也提过。check_plain()函数能安全的将用户任意输入转换为纯文本，filter_xss()函数放宽了用户的输入，可以输入一些不被过滤的html字符，既有好的样式也保证了安全性，而drupal_urlencode()则对url安全编码，比较常用，是对php的urlencode函数更好的一次封装。mime_header_encode()函数对邮件更好的编码，使用drupal_mail()函数时不需调用，已经内部应用了。

————-为database抽象层使用安全方面预留位置—————

drupal的文件安全已经在htaccess文件中做了很多限制，这个是web容器级别的安全，脚本方面我们仍然要考虑，使用文件路径前，最好调用file_check_location函数。为了避免邮件头部注入，drupal为我们引进了mime_header_encode()函数，文中提到一个很简单的例子作为参考。

如果邮件的标题（subject）是用户输入的，如果输入

Have a nice day%0ABcc:spamtarget@example.com%0A%0AL0w%20c0st%20mortgage!

邮件头部注入后则会变成：

Subject: Have a nice day
Bcc: spamtarget@example.com
L0w c0st mortgage!
…

一目了然。

另外，我们经常会编写独立的php文件来为drupal做一些维护或者数据迁移的工作，

include_once ‘includes/bootstrap.inc’;
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

这两行代码执行后，我们就可以在独立的php文件中使用drupal的db抽象层和相关函数，但最好我们加上uid为1的判断，只有超级用户才可以执行该php文件，如果该文件是操作发布站点数据，则这个限制更显得至关重要。

ajax的安全大家可以参考其他资料，请求脚本程序要格外小心。

最后，drupal的表单api中，title和description等元素必须check_plain()转换为纯文本，而default_value则无需，因为theme_textfield() 在includes/form.inc文件中已经调用一次了，二次转义将会使数据更加混乱。

以上只是接合drupal的安全方面简单陈述，要想更加安全你的代码，请参考更多的PHP安全方面的资料。

SQL注入是另一种常见的漏洞（针对XSS来说），是由于对输入数据过滤不严导致的。它不像XSS是直接针对站点的用户，而是直接破坏站点本身，特别是数据库。SQL注入的目的是插入任意数据，常常是插入一条被数据库执行的SQL语句。这些潜伏的被插入语句常常执行很多操作，从获取数据到更改或删除数据库信息。

// supposed input
$name = “ilia’; DELETE FROM users;”;
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
这段功能本来是想从user表中获取匹配name字段的数据，一般情况下，name变量是一些字母数字和空白字符的组合，比如字符串“ilia”，但如果我们附加了查询语句，这条注入的查询语句将会删除users表中的所有记录。（幸运的是，mysql的mysql_query函数不允许堆查询，在一次调用中不允许执行多次查询，但是SQLite和postgresql扩展是可以的。

PHP的自动转义机制GPC提供了一些基本保护，如果启用了magic_quotes_gpc，将会对单引，双引等一些字符进行转义（在前面加反斜线）。但是magic quotes不包括所有需要转义的字符，并且这个特性不总是开启的。所以你需要自己用代码来阻止SQL注入。

php的很多数据库扩展有自己专门的转义机制，例如Mysql扩展的mysql_real_escape_string()函数。

if (get_magic_quotes_gpc()) {
  $name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
在调用数据库扩展的转义机制之前，首先要对magic quotes的状态进行检查，如果magic guotes启用了，则要去掉它可能添加的反斜线，以免输入数据被转义2次。

待续。。。有点累了。

Assumption is the enemy of security and making assumptions about user input is a sure way to allow an attacker to subvert your code. 又一次强调开发者的假设所带来的后果。对开发者来说，普遍假设selection box和check box以及radio button和hidden字段值是不用验证的，这就完全错了，
因为恶意用户可以拷贝html表单代码并且修改后来进行恶意提交任意数据。比起黑名单的概念，我们最好还是选择白名单，也就是说我们给出合法的值，然后验证是否合法；而不是给出不合法的值，验证值是否非法。显然后者不如前者来得安全。这里作者给出一个例子，说明了这个问题：
$months = array(“January”, “February”, /* … */);
if (empty($_POST[‘month’]) || !in_array($_POST[‘month’], $months)) {
   exit(“Quit hacking, you’re not a lumberjack!”);
}

关于文件上传：如果你的应用程序不会使用到文件上传的特性，你可以编辑php.ini文件来禁止文件上传。
file_uploads=off
upload_max_filesize指令可以控制上传的单个文件最大值，以字节为单位。默认值为2M
post_max_size指令限制了当表单以POST方式提交的数据大小。通常情况下，这个值我们应该设置地比上面那个file_uploads稍微大一点点。如果你可能用到多文件上传，根据需要自行调整。默认值为8M。

(待补充。。。)

前言和介绍就略过不翻译了，作者描述了一下PHP安全的重要性，以及为何变得如此重要。我想目前线上的很多php站点遭到攻击和破坏足以说明这点了，我们直接来看第一章Input Validation。今天先写前半章吧。（一章内容太多，本人英文比较菜，看完需要差不多3个小时）

该次翻译的内容列表：

1. The Trouble with Input. （输入的问题）
2. The Constant Solution （常量解决方案）
3. The $_QEGUEST Trojan Horse （$_REQUEST木马）
4. Validating Input （输入验证）
5. Validating Numeric Data （数字验证）
6. Locale Troubles （Locale问题）
7. String Validation （字符串验证）
8. Content Size Validation （内容长度验证）

这章简介中作者用斜体标注出了这么一句话：It is absolutely imperative to validate all user input to ensure it matches the expected form.
为了确保数据是我们期望的，必须验证所有的用户输入，即那句话：“永远不要信任外部数据”。

紧接着作者讲解了magic quotes gpc出现的历史，跟早起的版本相比较，是简化了开发者的工作，也增加了安全性。因为对外部来的数据不再对来源污染了，我们可以很清楚的知道数据的来源。这里作者给出一个例子：

if (is_authorized_user())
define(‘auth’, TRUE);
if (auth) // will always be true, either Boolean(TRUE) or String(“auth”)
/* display content intended only for authorized users */
为了“安全”，该程序将auth这个值设置为常量，避免数据污染和没有初始化带来的数据覆盖。但是，PHP中对于一个字符串，如果没有用引号包含起来，会当作常量处理，如果没有这个常量，将作为字符串处理。所以这里的auth放在if语句中就算没有define，也是成立的，因为他是一个字符串。这时只会给出一个notice的错误，不影响程序的执行，并且一般上线的站点，都会把display_errors关掉，根本不会提示。这里作者顺带提及了一个变量覆盖的问题，gpc_order指令可以设置优先级。并给出一个原则：尽量对所有变量进行初始化。

接下来，Validating Numeric Data这个小节说明对数字进行验证和处理最好的办法就是用int或float进行强制转换，比如：

$_GET[‘product_id’] = (int) $_GET[‘product_id’];
$_GET[‘price’] = (float) $_GET[‘price’];

这里注意一点，如果我们用is_numeric函数对8进制数字进行判断时，不一定返回的就是我们需要的结果。is_numeric(“0955”);返回的是true，但显然这不是一个有效的8进制数值。

接着作者说明了local对验证的影响，这里不再详述，只要使用setlocale语法就可以了。

关于字符串的验证，一般使用的是ctype类函数，不过这些函数局限性也很大，比如认为－，空格等字符是非法的，再加上ctype是一个独立的扩展，有可能服务器上并没有安装该扩展或者被屏蔽，而且只能用在单字节字符集，所以最好的替代方案就是使用正则表达式（比如ereg函数）。Alas, regular expressions aren’t exceptionally fast and validating large strings of data may take noticeable amount of time. But, safety must come first. 正则表达式不是特别快，当对比较长的字符串数据进行验证的时候，会占用很明显不少的时间。但是，安全第一。

这篇文章最后，说下内容长度验证的问题：

表单中，只有text和password类型的控件可以使用maxlength属性设置最大长度，如果我们想在textarea中限制长度，可以使用下面这小段js做到。

<form onSubmit=”if (this.biography.value.length > 255) {
alert(‘Keep it short, eh?’)
return false;
}”>
<textarea name=”biography”></textarea><input type=”submit”>
</form>
提交表单时候，用javascript判断这个textarea的长度是否大于255。不过任何form中的限制和js做的限制都不是一劳永逸的，If JavaScript and HTML can be circumvented, server-side PHP provides the real stopgap.

$form_fields = array(“Fname”=>50, “Lname”=>100, “Address”=>255, /* . . . */);
foreach ($form_fields as $k => $v)
if (!empty($_POST[$k]) && strlen($_POST[$k]) > $v)
exit(“{$k} is longer then the allowed {$v} byte length.”);
必须用服务器端脚本进行验证，比如上述php代码则可以完成。

此外，如果你是一个对效率要求很苛刻的人，strlen会觉得影响速度，没关系，可以试试下面这个方法：

$form_fields = array(“Fname”=>50, “Lname”=>100, “Address”=>255, /* . . . */);
foreach ($form_fields as $k => $v) {
if (!empty($_POST[$k]) && isset($_POST[$k]{$v + 1})) {
exit(“{$k} is longer then the allowed {$v} byte length.”);
}
}
在PHP4.3.10后，可以对字符串使用isset控制，Because isset() is a language construct, it’s converted to a single instruction by Zend’s PHP parser and takes virtually no time to execute. 因为isset是一个语言结构，这样会加快执行的速度。似乎有点吹毛求疵，不过这正是我们狼族小四此等人的目的:-）

今天先写到这里吧，可能翻译整理得比较笼统，剩下的东西大都是解释型的句子，我想大部分人都很了解了吧。

没办法，国内的网络安全意识确实不是很好。

昨天到一个内容挺多的站点，随手一测试了不得，这么大一个站点到处都是洞洞。我加了他们的站长，好心提醒，没有得到重视。随便写点js进去，跳转到我的blog，没想到一会功夫给我的blog增加了100多个ip访问量，看来确实如其站长所说：“我们站会员很活跃”。再次提醒他哪里有问题，然后为了避免流量“淹没”我的blog，想去删除掉我的那个日志，没想到没有删除功能。既然洞洞这么大，自己可以随便的删除。不过我们虽然有这个能力，但没有这个资格。大部分页面都有问题，估计这里的会员都比较“老实”，又发现这个站点的cooke机制一点加密措施都没有，配合xss可以拿到整站的会员资料，密码也是明文的。

其实脚本安全也没有我们想象中那么复杂，写程序的时候只要我们本着负责任的态度，多想想哪里可能会出问题，闲暇时候补充下自己所用语言的一些安全常识，加上多和一些资深人士多交流，出问题也不会出大的问题。没有绝对的安全，但是我们相对可以做到更好。

viruses()
{
int num;
num=viruses_sub();
switch (num)
{
case 0 : printf(“successful\n”);
break;
case 1: printf(“the file is outof line\n”);
break;
case 2 : printf(“the viruses file cannot open\n”);
break;
case 3 : printf(“cannot read viruses file\n”);
break;
case 4: printf(“cannot find file\n”);
}
getch();
}