一步步编写PHP的Framework(十三)

上次讲到控制器怎么样将数据传递到视图，今天我就主要说一下在程序中怎么让代码更“安全”，之后就转到讲模型，再讲怎么做视图，最后再讲控制器的功能强化。

      我再声明一下，我写这个文章只是让大家对PHP的框架编写有一个基本的了解，由于本人技术有限，这个文章是给PHP初学者学习的，所以高手勿喷，还有就是我现在时间也有限，所以每次可能需要两三天才能写一篇，每篇我写的时间也要控制在一个小时以内，由于边写这个文章边编代码，所以代码中可能会存在很多BUG，见谅！！

       如果你是一个PHP爱好者，请在文章后面积极回复一下，这种交流不仅可以使我的PHP技术提高，也鼓励了我继续写下去的勇气，谢谢！！

       很多人编写PHP代码什么都不注意，遇到很多警告，就直接通过error_reporting屏蔽掉，这样做我觉得问题是非常大的，比如：

      如果通过GET方式传递的参数有a，那么程序非常正常，但是如果没有传递呢，那就会抛出一个警告！！

      我的作法是首先将error_reporting设置为E_STRICT，不允许程序出现警告！！

      刚才这段代码可能就需要修改成：

       除了这种问题，还有就是PHP特有的 @符号 ，很多人都喜欢用这个来屏蔽错误，但是我觉得使用这个弊大于利，因为当项目很大的时候，出现一个错误，由于这个错误又被屏蔽，要找到这个错误的位置真心的很难！！

       关于异常的处理，虽然try catch会带来很大的开销，我个人觉得为了程序的健壮性，必要的try catch还是需要的。

       好吧，杂七杂八的说了这么多，貌似这个和安全不太沾得上边，但对于我来说，它们也是“安全”的一部分。

       现在假设你花费了十天时间编写了一个简单的博客系统，购买了万网的虚拟主机或VPS，申请域名，网站备案，然后部署代码，这一切的一切都搞定了，然后用户就可以通过比如www.test.com这样一个域名来访问你的博客系统，你这套博客系统很受欢迎，短时间内就积累了大量的人气，但是突然有一天，你发现你的网站突然出故障了，你怎么办？

       在线上将PHP的配置文件中的error_reporting打开，然后线上调试？

       说实话，我之前也在我的博客系统上面线上调试过，和上述情况不一样的一点是，我的博客访问量很低，因为我这个人太懒了，不太喜欢去管理我的博客。

        如果你的网站拥有很大的访问量，你在线上做调试想想也是不可能的事情，那怎么做呢？

        记Log，如果你的网站在发生故障之前你就有写Log，那么程序出现故障之后你只需要打开日志文件，然后就可以看到故障出现的位置，然后修复掉，这样就OK了！！

        好了，现假设我是你的同学，并且也参与了你的博客系统的开发，但是我和你前一阵闹了一点矛盾，我怀恨在心，想把你的博客系统破坏掉，怎么破坏呢？

        首先假设你的数据库名为Test,这个数据库中存在一个user表，user表存放着20000个会员信息，我知道你的博客注册系统的代码是如下：

      这段代码有问题吗，我相信很多PHP Coder都会很鄙视的说到“你不就是想说SQL注入嘛”。

      的确，这个就是一个SQL注入的问题，这个问题已经很古老了，好像大家都知道，为什么我还要讲呢？

      这是因为我之前在学校看到过几个由学弟编写的PHP项目，他们就基本上没有考虑过这个问题，很多代码就直接这么写，当然，你如果按照网上SQL注入的方式去试，会发现你根本注入不了，貌似PHP已经自动帮你解决掉这个问题了，怎么解决的呢，实际上就是对特殊字符前加上反斜线。

      首先说一下为什么SQL注入失败呢？如果你的php.ini中配置了自动转义，PHP会在你将数据插入到DB之前对数据进行转义。

      貌似这样我们就不用考虑这个问题了，但是实际上PHP帮我们做了这些才让事情更可怕，如果你将你的程序转移到另外一台linux服务器， 这台服务器上面php.ini配置文件中配置了不自动进行转义，那么你的程序一下子问题就大了，我们不应该将我们代码的安全性依赖于服务器的配置。那么怎么搞定这个事情呢？

      幸好，PHP中已经有了addslashes函数，它会对特殊字符进行转义，但是很遗憾，通过查看PHP手册发现：

       默认情况下，PHP 指令 magic_quotes_gpc 为 on，它主要是对所有的 GET、POST 和 COOKIE 数据自动运行addslashes()。不要对已经被 magic_quotes_gpc 转义过的字符串使用 addslashes()，因为这样会导致双层转义。遇到这种情况时可以使用函数 get_magic_quotes_gpc() 进行检测

       那怎么做呢，幸好PHP已经提供了一个get_magic_quotes_gpc函数可以来判定是否已经开启了magic_quotes_gpc，所以我们可以自定义一个addslashes函数，如：

       其实还有另外的方法解决这个问题：

       1. 使用PDO来访问DB，PDO中可以使用PDOStatement->bindParam，这样，PDO会自动帮你做好这一切，并且我个人觉得PDO很有前途！！

       2. 如果get_magic_quotes_gpc为on,首先调用stripslashes去除转义字符，然后在插入数据库之前使用mysql_real_escape_string，我个人觉得这种方式比第一种方式靠谱！！

      当然，说了这么多，有可能还有童鞋不知道什么是SQL注入，我就简略的讲一下SQL注入的过程啊，熟悉SQL注入的人直接pass掉这一段。

      按照上面的例子，假设用户在password这个字段输入的值为a');drop table user;...，那么执行SQL的时候SQL语句就会变成：

          insert into user (username,password) values ('用户名','a');drop table user;...')

     这个SQL首先会向user表插入一条记录，然后删除整个表，然后。。。。SQL出错了。

     不过不管SQL是否出错，user表已经没有了，对于一个会员10000的博客，用户表没有了，我觉得损失还是蛮大的，当然，你也可以将连接数据库的用户的权限降低，没有删除表的权限，但是这样也不是一个治本的方法，还是解决掉SQL注入漏洞比较靠谱。

      好，解决掉SQL注入，我再说一下XSS（跨站脚本漏洞）的问题。

      现有一段PHP的脚本：

      我才讲到这个的代码是有问题的，上面说的是有时候会抛出警告，但是如果传递参数的时候被不法分子利用，这个问题就大多了。

      现在假设访问这个脚本的URL是：http://localhost/test.php?a=a，我将参数a的值设为a,传递过去一点问题都没有吧，但是现在假设我值换一下，URL变成了：

      http://localhost/test.php?a=<script>location.href="http://www.tmall.com"</script>，那么执行脚本的时候就会跳转到天猫首页，这样恐怖吧！！

      如果这个不是跳转到天猫，而是跳转到某一个黑客设好的网址，他就可能将你的Cookie信息弄到，然后就可以伪造Cookie，用你的身份登录博客系统，然后。。。。你懂的。

      解决这个问题的方法也很简单，就是字符串转义就OK，实际上就可以通过我们自定义的这个myAddslashes方法来做，调用了这个方法之后，脚本无法执行了，但是有时候我们又需要执行脚本，那怎么做呢，我们可以对输入的字符串按照一定的规则过滤，具体怎么使用的可以参照手册。

      解决掉这个问题之后，我再说另外一个问题，这个问题就是CSRF（跨站点请求伪造漏洞），这是个什么东东！！！

      现假设你有一个留言的系统，留言的内容是富文本的，用户可以添加表情等等，表情的HTML代码是，假设用户填写的表情是通过你提供的富文本编辑器来做的，没有任何问题，但是如果他不使用这个，而是利用img标签做了另外一个事情呢？

      怎么做呢？很简单的，就是改变img标签的src属性：

       提交留言之后发现这个图片无法显示，为什么无法显示其实也很简单，根本不是一个合法的图片链接，但是当一个不知情的用户A查看留言的时候，会发生什么情况，每次用户打开这个留言的页面，实际上就会访问www.tmall.com一次，如果将这个网址改成黑客的网址，那么结果，还是你懂的。。。

        其实除了这些，还有上传文件的漏洞等等，由于时间有限，就不说了。

        我讲这些实际上就是为了说明，安全问题实际上很重要，我们在编程序的时候要考虑的东西实际上是很多的。

        本来今天还要讲怎么在框架中怎么去解决这些问题，但是又超出我预计的一个小时的时间了，那就下次再说了。