浅谈 PHP 安全开发

注：本文为“小米安全中心”原创，转载请联系“小米安全中心”

上期回顾： 基于burp插件的安全测试

PHP作为世界上最好的语言(⊙﹏⊙)，在WEB开发中应用广泛，同时也经常会产生各种漏洞，那么我们该怎样有效的防护这些漏洞呢？今天就来讨论下PHP开发安全防护。

当年PHP还是PHP4这个版本时，多数项目用着混编的模式（前端代码和PHP代码未分离）进行编码、手写拼接SQL语句、echo直接输出，这些习惯也被延续到了今天。由于没有良好的工程结构、没有安全意识导致很多老项目漏洞百出，这种项目让开发人员最为头疼。

PHP安全开发第一步，你需要使用一个优秀的PHP框架。一个优秀的框架不仅有着良好的工程结构，也往往在安全防御上有很多有用的类库、开关。今天介绍的PHP开发安全防护也是基于框架来说的。 PHP框架数不胜数，很多PHP开发人员都自己写过框架，但优秀且常用的PHP框架也就那么几个，如经典的Codeigniter、优雅的Laravel、执行速度最快的Yaf等等。下面涉及到框架方面的东西都是基于Laravel框架进行讨论。

框架的基本思想大同小异，基本上其核心都是MVC、MVP这几种模式，而我们常见的漏洞也就处在这几层上面，如：Model层造成SQL注入漏洞、Controller层造成逻辑漏洞、View层造成XSS漏洞。

SQL注入

SQL注入的造成是因为执行了非预期的SQL语句，而这种情况往往是由于开发图省事，喜欢直接写SQL语句，但又没有对用户输入进行过滤或者过滤不严格造成的。使用Laravel你不必去拼接SQL，而是很优雅的调用模型提供的方法。

Laravel提供了一套非常完备的ORM模型，同时使用预处理方式执行SQL语句，而预处理就是解决SQL注入的银弹。什么是预处理语句？可以把它看作是想要运行的 SQL 的一种编译过的模板，它可以使用变量参数进行定制。

预处理语句可以带来两大好处：

1. 提高运行效率

2. 防止SQL注入

预处理过程中，程序会将SQL执行分为两次发送给MySQL，第一次发送预声明SQL语句,形如select *from users where username = ?

第二次发送执行绑定的参数值，如:root

由于是将SQL语句和值分开发送的，再由MySQL内部执行，这样就不会出现执行非预期的SQL语句情况。预处理可以说是最简单有效的防止SQL注入的方式。

不过使用预处理方式也是有条件的，PDO中有一个属性PDO::ATTR_EMULATE_PREPARES，默认是true，它将强制PDO总是模拟预处理语句。

测试一段代码：

抓包查看：

可以看到并没有使用MySQL预处理的方式，而是进行的转义。所以使用预处理方式需要将PDO::ATTR_EMULATE_PREPARES设置为false。

XSS

相比于SQL注入，XSS的防御要困难些，稍不留神就会产生纰漏。这也就需要我们在开发过程中时刻保持警惕每一个数据的输出是否进行编码。

XSS分为反射型XSS、存储型XSS、基于DOM的XSS。

其造成的原因分为两类：

1. 视图没有进行编码直接输出造成(存储型XSS)  

2. JS获取用户输入数据没有对其进行编码或过滤不妥当造成(反射型XSS、基于DOM的XSS)。

1.视图没有进行编码直接输出

这种情况，通常有两种方式处理：

（ 1 ）在用户提交数据时将数据进行编码保存到数据库，视图直接渲染输出。

这样处理后的数据将被使用到很多地方，因为HTML编码和JS的编码方式是不同的，那么在不同的地方，显示出来的效果也是不同的。

（ 2 ）原样保存用户提交的数据，在页面渲染时对用户提交后的数据进行编码展示。

这种方式需要在每一个地方进行编码，给开发带来了不小的工作量，但好处是可以针对不同情况做相应处理。很多系统也是采用这种方式，但也容易因为没有编码直接输出造成XSS。这个时候框架的优势就体现出来了，往往框架都会有自己的模板语言，模板渲染时会自动将输出内容进行html编码。

例如Laravel里面的输出使用模板标签{{ $content }}，它会经过内部函数e()进行编码再输出，你就不用考虑编码的问题了。当然也有不用模板标签的地方，如ajax请求返回JSON数据是不需要使用模板标签的，这种情况就需要你根据情况主动调用编码函数。

2.JS获取用户输入数据没有对其进行编码或过滤不妥当

JS获取用户输入的数据可能会插入到html中，这个时候就需要对其进行htmlEncode；也可能作为JS变量的值进行传递，这个时候就需要对其进行javascriptEncode；还有可能输出在地址栏里，这个时候就要对其进行urlEncode

CSRF

CSRF的防护通常有两种方式：

1. 验证HTTP Referer字段

2. 在请求提交中添加Csrf Token并验证

第一种方式简单快捷，只需要在所有提交处验证一下Referer。但它不能防止站内的请求伪造。例如：pay.example.com/abc.html 存在一个XSS漏洞，那么我可以利用这个XSS漏洞伪造一个 pay.example.com/pay.php 的请求，如果程序只验证Referer是有效的，那么这个攻击就造成了。

第二种方式，需要我们在每一个请求处加上一个随机的token值，并且在所有的提交前判断一下这个token值的有效性。

两种方式需要在每个请求后作出的处理，框架有一个“中间件”层，这个中间件层作用在整个生命周期。

用户每一请求，都会执行到验证Csrf Token的程序，程序通过验证请求中的token值与服务端session中保存的token值是否相等来判断本次请求是否合法。

往期回顾：

基于burp插件的安全测试

证书检测二三事

自动化web安全测试

中、小企业如何自建免费的云WAF

利用恶意软件检测服务向服务提供商植入恶意软件(二)

利用恶意软件检测服务向服务提供商植入恶意软件(一)

问题

以上粗浅的描述，细节方面有待深究。抛砖引玉，请问在开发过程中你是如何对常见漏洞进行防御？

参与详情

参与方式：点击下方“写留言”， 在开发过程中你是如何对常见漏洞进行防御？

参与时间：截止至9月18日18：00 （要注意参与时间哦~）

获奖方式

• 在精选留言中，选出 作者满意的留言 送出精美礼品

（在众多留言中，择优选择部分留言移为精选留言，展示出来。所有的幸运小伙伴，都会是作者亲自选出哦~如果留言质量不高的话，我们会把礼物留到下一次做活动哦~）