php 项目代码的安全总结

1: 基础型,
    include $module.'.php'; $module假如直接用GET上得到, 那这是个非常毁灭性的bug, linux下让你痛不欲生, windows下让你倾家当产, 这类安全性一般都会被人直接发现, 而有效地阻止. 假如你连这点都没做到, 请问你是否称得上合格的程序员?

  2: 质的安全.
    许多人会说, 外部变量应该addslashes一次, 我们先不管addslashes函数是否高效安全, 许多人其实忘记了在使用addslashes之前, 也得注意安全. index.php?aa[]=222&, 这是url, addslashes($aa); 系统会报错. 由此可见, 我们在使用函数的同时, 理应知道数据类型的不同, 会产生哪种情况. 以前有文章说过, 函数注册了传参数>0数字型, 用户传入字母,怎么办. 许多人认为是函数的错误, 在我看来, 是使用者的错误, 虽然是自定义函数, 不过你瞒目的传参数, 不解其中原由, 这点态度上已经很不安全.

  3: 压力安全.
    目前你偶尔看163的新闻, 会发现, 浏览器会突然崩溃, 假死, 甚至浏览器"被关闭". 这个原因有可能是网页程序代码问题, 也有可能是前端js的问题, 特别是js, 由于js特性比较灵活, 在使用循环, 赋值方面, 不容易查错, 比较突出的一点在于取值及错误再处理. 比如getelementbyid('mydiv'); 这时, 你是否有想过, mydiv是否存在? 是否被二次修改? 还有一点是图片, 许多人在图片无法加载时, 都用onerror去再次显示默认图片, 你是否有想过, 假如默认图片也无法显示呢? 是不是进入无限循环了?

  4: PHP性能安全.
    没有人能够说从来没遇到过无限循环导致apache崩溃的, 再优秀的人也都有相同的体会. 循环到底都产生了什么压力? 影响了哪些性能? 见一段代码:
    foreach($array AS $val){
     $payarr = include('pay.inc.php');
     if($payarr[0] >= 360 * 1.25 + 568){
  $err[] = $payarr[0];
     }
    }
    这段代码是可以正常运行的, 不管你include是否成功, 不用判断是否有意义, 反正它是可以运行成功的. 当然, 它是无意义的. 要真正实现功能需求, 这段代码得增加好几行, 全部是判断. 在引入文件前, 是否应该先is_file确认文件是否存在? 既然是在循环中, 是否应该使用include_once? 条件值是数字运算, 是否写个直接值比较好?  在判断前, 是否应该先判断$payarr数组值存在与否?

  5: 在写程序还是写判断.
    上面的性能安全讲了缺少了许多判断, 那php是否有文档显示, 无谓的判断是否影响性能. 见代码.
    if(is_resource($a) === false || is_array($a) === false || is_bool($a) === false)
    echo $a;
    假如我们每次使用变量时都这样判断? 是不是更安全? 代码是没错的, echo 仅打印字符串类型, 前面的判断也是符合逻辑思维. 这可能比较像严格型安全, 但如果php能够省略这点性能压力, 这样写也未必不是好事. 至少实现了需求, 也增加了安全性. 当然我们也会在想, 这样写的话, 我到底是在写程序还是在写判断?

  6: 屏蔽错误.
    许多人在学习php时, 老师关于安全上说过的一句话, 让他深深记住了, 屏蔽错误信息. 个人认为, 屏蔽错误应该是有前提条件的. 即屏蔽显示出来, 但不能屏蔽记录. 某天, 一个网页空白了, 让程序员查错误, 他告诉我, 错误被屏蔽了. 你认为这样合理? 我是让你屏蔽错误, 但没让你自己也把自己屏蔽了, 连你自己都不知道错误在哪, 普通用户能知道? 所以, 你在使用php.ini屏蔽, 或者@符时, 切记, 你自己得清楚错误发生在哪.

  7: 接口安全.
    相信大家都有做接口安全, 不管你们有木有, 反正我是有的. 通常的做法就是, 请求url,然后php打印值给客户端, 这样客户端就可以做判断处理, 或者显示处理. 事实上, 这种做法, 普通的php工作人员很容易通过firebug来得到url,即可知道你得到的参数是什么, 返回的值是什么, 这是潜在的危险, 比如商品评论, 商品价格. 为此, 我建议接口做一层token, 先取token然后再传参数. tokey所做的工作非常有意义, 可以计算用户是否正常, ip, 请求时间. 在下一步请求接口时, 便可判断. token值是加密的, 用户无法使用或者保留, 你也许会问, token就一串字符, 它可以一直保留着请求接口呀. 我滴神. 麻烦把请求时间使用起来呀.

  8: 显示安全.
    其实我自己也没完全搞懂显示安全这问题. 比如需要记录用户的签名吧, 支持html代码. 那提交后, 入库mysql前, 数据是addslashes,还是htmlspecialchars呢? 假如是addslashes的话, 那前台显示时, 就有可能被人xss注入. 假如htmlspecialchars的话, 那前台显示时, 怎么把html代码给显示出来? 同时又可以防止xss呢?一个网站那么多变量, 你有一个一个去思考这个问题么? 怎么防止攻击?

  9: 蛋疼的安全.
    不管你们是否相信, 反正我相信sohpex会蛋疼, zend加密后的代码似乎在php5.3版本后无法使用. 你这安全做得太不靠谱了, 原来是公关安全, 竟然移交给程序员去实现. 商业模式不带这样玩的