PHP安全把握整站的结构

把握整站的结构，避免泄露站点敏感目录

    在安全性上，一个入口点文件也能隐藏后台地址。像这样的地址http://localhost/?act=xxx不会暴露后台绝对路径，甚至可以经常更改，不用改变太多代码。一个入口点文件也可以验证访问者的身份，比如一个网站后台，不是管理员就不允许查看任何页面。在入口点文件中就可以验证身份，如果没有登录，就输出404页面。

有了入口点文件，我就把所有非入口点文件前面加上了这句话：

<?php if(!defined('WWW_ROOT')) {header("HTTP/1.1 404 Not Found"); exit;} ?>

使用预编译语句，避免sql注入

    注入是早前很大的一个问题，不过近些年因为大家比较重视这个问题，所以慢慢变得好了很多。

    吴翰清在web白帽子里说的很好，其实很多漏洞，像sql注入或xss，都是将“数据”和“代码”没有区分开。“代码”是程序员写的内容，“数据”是用户可以改变的内容。如果我们写一个sql语句select * from admin where username='admin' password='xxxxx', admin和xxxxx就是数据，是用户输入的用户名和密码，但如果没有任何处理，用户输入的就可能是“代码”，比如'or ''='，这样就造成了漏洞。“代码”是绝对不能让用户接触的。

    在php中，对于mysql数据库有两个模块，mysql和mysqli，mysqli的意思就是mysql improve。mysql的改进版，这个模块中就含有“预编译”这个概念。像上面那个sql语句，改一改：select * from admin where username='?' password='?'，它就不是一个sql语句了，但是可以通过mysqli的预编译功能先把他编译成stmt对象，在后期用户输入账号密码后，用stmt->bind_param将用户输入的“数据”绑定到这两个问号的位置。这样，用户输入的内容就只能是“数据”，而不可能变成“代码”。

    这两个问号限定了“数据”的位置，以及sql语句的结构。我们可以把我们所有的数据库操作都封装到一个类中，所有sql语句的执行都进行预编译。这样就完全避免了sql注入，这也是吴翰清最推荐的解决方案。

预防XSS代码，如果不需要使用cookie就不使用

    在我的网站中并没有使用cookie，更因为我对权限限制的很死，所以对于xss来说危险性比较小。

    对于xss的防御，也是一个道理，处理好“代码”和“数据”的关系。当然，这里的代码指的就是javascript代码或html代码。用户能控制的内容，我们一定要使用htmlspecialchars等函数来处理用户输入的数据，并且在javascript中要谨慎把内容输出到页面中。

限制用户权限，预防CSRF

    现在脚本漏洞比较火的就是越权行为，很多重要操作使用GET方式执行，或使用POST方式执行而没有核实执行者是否知情。

    CSRF很多同学可能比较陌生，其实举一个小例子就行了：

A、B都是某论坛用户，该论坛允许用户“赞”某篇文章，用户点“赞”其实是访问了这个页面：http://localhost/?act=support&articleid=12。这个时候，B如果把这个URL发送给A，A在不知情的情况下打开了它，等于说给articleid=12的文章赞了一次。

    所以该论坛换了种方式，通过POST方式来赞某篇文章。

    可以看到一个隐藏的input框里含有该文章的ID，这样就不能通过一个URL让A点击了。但是B可以做一个“极具诱惑力”的页面，其中某个按钮就写成这样一个表单，来诱惑A点击。A一点击，依旧还是赞了这篇文章。

    最后，该论坛只好把表单中增加了一个验证码。只有A输入验证码才能点赞。这样，彻底死了B的心。

    但是，你见过哪个论坛点“赞”也要输入验证码？

所以吴翰清在白帽子里也推荐了最好的方式，就是在表单中加入一个随机字符串token（由php生成，并保存在SESSION中），如果用户提交的这个随机字符串和SESSION中保存的字符串一致，才能赞。

    在B不知道A的随机字符串时，就不能越权操作了。

    我在网站中也多次使用了TOKEN，不管是GET方式还是POST方式，通常就能抵御99%的CSRF估计了。

严格控制上传文件类型

    上传漏洞是很致命的漏洞，只要存在任意文件上传漏洞，就能执行任意代码，拿到webshell。

    我在上传这部分，写了一个php类，通过白名单验证，来控制用户上传恶意文件。在客户端，我通过javascript先验证了用户选择的文件的类型，但这只是善意地提醒用户，最终验证部分，还是在服务端。

    白名单是必要的，你如果只允许上传图片，就设置成array('jpg','gif','png','bmp')，当用户上传来文件后，取它的文件名的后缀，用in_array验证是否在白名单中。

    在上传文件数组中，会有一个MIME类型，告诉服务端上传的文件类型是什么，但是它是不可靠的，是可以被修改的。在很多存在上传漏洞的网站中，都是只验证了MIME类型，而没有取文件名的后缀验证，导致上传任意文件。

    所以我们在类中完全可以忽略这个MIME类型，而只取文件名的后缀，如果在白名单中，才允许上传。

    当然，服务器的解析漏洞也是很多上传漏洞的突破点，所以我们尽量把上传的文件重命名，以“日期时间+随机数+白名单中后缀”的方式对上传的文件进行重命名，避免因为解析漏洞而造成任意代码执行。

加密混淆javascript代码，提高攻击门槛

    很多xss漏洞，都是黑客通过阅读javascript代码发现的，如果我们能把所有javascript代码混淆以及加密，让代码就算解密后也是混乱的（比如把所有变量名替换成其MD5 hash值），提高阅读的难度。

使用更高级的hash算法保存数据库中重要信息

    在这个硬盘容量大增的时期，很多人拥有很大的彩虹表，再加上类似于cmd5这样的网站的大行其道，单纯的md5已经等同于无物，所以我们迫切的需要更高级的hash算法，来保存我们数据库中的密码。

    所以后来出现了加salt的md5，比如discuz的密码就是加了salt。其实salt就是一个密码的“附加值”，比如A的密码是123456，而我们设置的salt是abc,这样保存到数据库的可能就是md5('123456abc')，增加了破解的难度。

    但是黑客只要得知了该用户的salt也能跑md5跑出来。因为现在的计算机的计算速度已经非常快了，一秒可以计算10亿次md5值，弱一点的密码分把钟就能跑出来。

    所以后来密码学上改进了hash，引进了一个概念：密钥延伸。说简单点就是增加计算hash的难度（比如把密码用md5()函数循环计算1000次），故意减慢计算hash所用的时间，以前一秒可以计算10亿次，改进后1秒只能计算100万次，速度慢了1000倍，这样，所需的时间也就增加了1000倍。

    那么对于我们，怎么使用一个安全的hash计算方法？大家可以翻阅emlog的源码，可以在include目录里面找到一个HashPaaword.php的文件，其实这就是个类，emlog用它来计算密码的hash。

    这个类有一个特点，每次计算出的hash值都不一样，所以黑客不能通过彩虹表等方式破解密码，只能用这个类中一个checkpassword方法来返回用户输入密码的正确性。而该函数又特意增加了计算hash的时间，所以黑客很难破解他们拿到的hash值。

    在最新的php5.5中，这种hash算法成为了一个正式的函数，以后就能使用该函数来hash我们的密码了。

验证码安全性

    这是我刚想到的一点，来补充一下。

    验证码通常是由php脚本生成的随机字符串，通过GD库的处理，制作成图片。真正的验证码字符串保存在SESSION中，然后把生成的图片展示给用户。用户填写了验证码提交后，在服务端上SESSION中的验证码进行比对。

    由此想到了我之前犯过的一个错误。验证码比对完成之后，不管是正确还是错误，我都没有清理SESSION。这样产生了一个问题，一旦一个用户第一次提交验证码成功，第二次以后不再访问生成验证码的脚本，这时候SESSION中的验证码并没有更新，也没有删除，导致验证码重复使用，起不到验证的作用。

    再就说到了验证码被识别的问题，wordpress包括emlog的程序我经常会借鉴，但他们所使用的验证码我却不敢恭维。很多垃圾评论都是验证码被机器识别后产生的，所以我后来也使用了一个复杂一点的验证码，据说是w3c推荐使用的。

   好了，我能想到的，也是在实际运用中用到的东西也就这么多了。这也仅仅是我自己写代码中积累的一些对代码安全性的一个见解，如果大家还有更好的想法，可以和我交流。希望大家也能写出更安全的代码。