最佳实践系列（三）--PHP安全三板斧：过滤、验证和转义之过滤篇_html/css_WEB-ITnose

• $_GET
• $_POST
• $_REQUEST
• $_COOKIE
• $argv
• php://stdin
• php://input
• file_get_contents()
• 远程数据库
• 远程API
• 来自客户端的数据

所有这些外部源都可能是攻击媒介，可能会（有意或无意）把恶意数据注入PHP脚本。编写接收用户输入然后渲染输出的PHP脚本很容易，可是要安全实现的话，需要下一番功夫。我这里以陈咬金的三板斧为引子，给大家介绍三招：过滤输入、验证数据，以及转义输出。

1、过滤输入

过滤输入是指转义或删除不安全的字符。在数据到达应用的存储层之前，一定要过滤输入数据，这是第一道防线。假如网站的评论框接受HTML，用户可以随意在评论中加入恶意的

如果不过滤这个评论，恶意代码会存入数据库，然后在网页中渲染，当用户访问这个页面时，会重定向到可能不安全的钓鱼网站（这种攻击有一个更专业的称呼：XSS攻击）。这个简单示例很好的说明了为什么我们要过滤不受自己控制的输入数据。通常我们要过滤的输入数据包括HTML、SQL查询以及用户资料等。

HTML

我们可以使用PHP提供的 htmlentities函数过滤HTML，该函数会将所有HTML标签字符（&、<、>等）转化为对应的HTML实体，以便在应用存储层取出后安全渲染。但是有时候我们是允许用户输入某些HTML元素的，尤其是输入富文本的时候，不如图片、链接这些，但是 htmlentities不能验证HTML，检测不出输入字符串的字符集，故而无法实现这样的功能。

htmlentities的第一个参数表示要处理的HTML字符串，第二个参数表示要转义单引号，第三个参数表示输入字符串的字符集编码。

与 htmlentities相对的是 html_entity_decode方法，该方法会将所有HTML实体转化为对应的HTML标签。

此外，PHP还提供了一个类似的内置函数 htmlspecialchars，该函数也是用于将HTML标签字符转化为HTML实体，只是能够转化的字符有限（参考官方文档： http://php.com/manual/zh/function.htmlspecialchars.php），如果要转化所有字符还是使用 htmlentities方法，值得一提的是和 htmlentities一样， htmlspecialchars也有一个与之相对的方法 htmlspecialchars_decode。

如果想要直接将输入字符串中的所有HTML标签去掉，可以使用 strip_tags方法。

如果需要更加强大的过滤HTML功能，可以使用HTML Purifier库，这是一个很强健且安全的PHP库，专门用于使用指定规则过滤HTML输入。在Laravel中我们可以使用相应的扩展包来实现过滤功能： http://laravelacademy.org/post/3914.html

SQL查询

有时候应用必须根据输入数据构建SQL查询，这些数据可能来自HTTP请求的查询字符串，也可能来自HTTP请求的URI片段，一不小心，就有可能被不怀好意的人利用进行SQL注入攻击（拼接SQL语句对数据库进行破坏或者获取敏感信息）。很多初级的程序员可能会这么写代码：

$sql = sprintf(    'UPDATE users SET password = “%s” WHERE id = %s’,    $_POST[‘password’],    $_GET[‘id’]);

这么做风险很大，比如某个人通过如下方式对HTTP发送请求：

POST /user?id=1 HTTP/1.1Content-Length: 17Content-Type: application/x-www-form-urlencodedpassword=abc”;--

这个HTTP请求会把每个用户的密码都设置为 abc，因为很多SQL数据库把—视作注释的开头，所以会忽略后续文本。

在SQL查询中一定不能使用未过滤的输入数据，如果要在SQL查询中使用输入数据，一定要使用PDO预处理语句（PDO是PHP内置的数据库抽象层，为不同的数据库驱动提供统一接口），PDO预处理语句是PDO提供的一个功能，可以用于过滤外部数据，然后把过滤后的数据嵌入SQL语句，避免出现上述SQL注入问题，此外预处理语句一次编译多次运行，可以有效减少对系统资源的占用，获取更高的执行效率。关于PDO后我们后续还会在数据库部分重点讨论。

值得注意的是，很多现代PHP框架都使用了MVC架构模式，将数据库的操作封装到了Model层，框架底层已经做好了对SQL注入的规避，只要我们使用模型类提供的方法执行对数据库的操作，基本上可以避免SQL注入风险。

我们以Laravel为例看看底层是如何规避SQL注入的，改写上面的 update语句，代码会是这样：

$id = $_GET['id'];$password = $_POST['password'];User::find($id)->update(['password'=>bcrypt($password)]);

由于模型类底层调用的是是查询构建器的方法，所以最终会调用Builder（ Illuminate\Database\Query\Builder）的 update方法：

public function update(array $values){    $bindings = array_values(array_merge($values, $this->getBindings()));    $sql = $this->grammar->compileUpdate($this, $values);    return $this->connection->update($sql, $this->cleanBindings($bindings));}

这段代码传入参数是要更新的值，然后通过 $bindings获得绑定关系，这里我们我们获取到的应该是包含 password和 updated_at（默认更新时间戳）的数组，然后再通过Grammar（ Illuminate\Database\Query\Grammars\Grammar）类的 compileUpdate方法生成预处理SQL语句，这里对应的sql语句是：

update `users` set `password` = ?, `updated_at` = ? where `id` = ?

然后最终将预处理sql语句和对应绑定关系传递给数据库去执行。关于SQL注入我们还会在后续数据库部分继续讨论。