PHP安全把握整站的结构,避免泄露站点敏感目录
2015-12-12 16:50
489 查看
摘要:这段时间一直在写一个整站,前几天才基本完成了,所以抽个时间写了一篇对于php安全的总结。技术含量不高,过不了也没关系,希望能一些准备写网站的朋友一点引导。...
这段时间一直在写一个整站,前几天才基本完成了,所以抽个时间写了一篇对于php安全的总结。技术含量不高,过不了也没关系,希望能一些准备写网站的朋友一点引导。
在放假之初,我抽时间看了《白帽子讲web安全》,吴翰清基本上把web安全中所有能够遇到的问题、解决思路归纳总结得很清晰,也是我这一次整体代码安全性的基石。
我希望能分如下几个方面来分享自己的经验
把握整站的结构,避免泄露站点敏感目录
在写代码之初,我也是像很多老源码一样,在根目录下放上index.php、register.php、login.php,用户点击注册页面,就跳转到http://localhost/register.php。并没有太多的结构的思想,像这样的代码结构,最大的问题倒不是安全性问题,而是代码扩展与移植问题。
在写代码的过程中,我们常要对代码进行修改,这时候如果代码没有统一的一个入口点,我们可能要改很多地方。后来我读了一点emlog的代码,发现网站真正的前端代码都在模板目录里,而根目录下就只有入口点文件和配置文件。这才顿悟,对整个网站的结构进行了修改。
网站根目录下放上一个入口点文件,让它来对整个网站所有页面进行管理,这个时候注册页面变成了http://localhost/?act=register,任何页面只是act的一个参数,在得到这个参数后,再用一个switch来选择要包含的文件内容。在这个入口点文件中,还可以包含一些常量的定义,比如网站的绝对路径、网站的地址、数据库用户密码。以后我们在脚本的编写中,尽量使用绝对路径而不要使用相对路径(否则脚本如果改变位置,代码也要变),而这个绝对路径就来自入口点文件中的定义。
当然,在安全性上,一个入口点文件也能隐藏后台地址。像这样的地址http://localhost/?act=xxx不会暴露后台绝对路径,甚至可以经常更改,不用改变太多代码。一个入口点文件也可以验证访问者的身份,比如一个网站后台,不是管理员就不允许查看任何页面。在入口点文件中就可以验证身份,如果没有登录,就输出404页面。
有了入口点文件,我就把所有非入口点文件前面加上了这句话:
WWW_ROOT是我在入口点中定义的一个常量,如果用户是通过这个页面的绝对路径访问(http://localhost/register.php),我就输出404错误;只有通过入口点访问(http://localhost/?act=register),才能执行后面的代码。
使用预编译语句,避免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注入,这也是吴翰清最推荐的解决方案。
下面是使用mysqli的一些代码部分(所有的判断函数运行成功或失败的代码我都省略了,但不代表不重要):
?
预防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推荐使用的。
如果大家需要,可以到这里下载http://pan.baidu.com/s/1bnb8Zmf
好了,我能想到的,也是在实际运用中用到的东西也就这么多了。这也仅仅是我自己写代码中积累的一些对代码安全性的一个见解,如果大家还有更好的想法,可以和我交流。希望大家也能写出更安全的代码。
转载请注明来源:PHP安全把握整站的结构,避免泄露站点敏感目录
http://www.php1.cn/Content/PHP_AnQuanBaWoZhengZhanDeJieGouBiMianXieLuZhanDianMinGanMuLu.html
这段时间一直在写一个整站,前几天才基本完成了,所以抽个时间写了一篇对于php安全的总结。技术含量不高,过不了也没关系,希望能一些准备写网站的朋友一点引导。
在放假之初,我抽时间看了《白帽子讲web安全》,吴翰清基本上把web安全中所有能够遇到的问题、解决思路归纳总结得很清晰,也是我这一次整体代码安全性的基石。
我希望能分如下几个方面来分享自己的经验
把握整站的结构,避免泄露站点敏感目录
在写代码之初,我也是像很多老源码一样,在根目录下放上index.php、register.php、login.php,用户点击注册页面,就跳转到http://localhost/register.php。并没有太多的结构的思想,像这样的代码结构,最大的问题倒不是安全性问题,而是代码扩展与移植问题。
在写代码的过程中,我们常要对代码进行修改,这时候如果代码没有统一的一个入口点,我们可能要改很多地方。后来我读了一点emlog的代码,发现网站真正的前端代码都在模板目录里,而根目录下就只有入口点文件和配置文件。这才顿悟,对整个网站的结构进行了修改。
网站根目录下放上一个入口点文件,让它来对整个网站所有页面进行管理,这个时候注册页面变成了http://localhost/?act=register,任何页面只是act的一个参数,在得到这个参数后,再用一个switch来选择要包含的文件内容。在这个入口点文件中,还可以包含一些常量的定义,比如网站的绝对路径、网站的地址、数据库用户密码。以后我们在脚本的编写中,尽量使用绝对路径而不要使用相对路径(否则脚本如果改变位置,代码也要变),而这个绝对路径就来自入口点文件中的定义。
当然,在安全性上,一个入口点文件也能隐藏后台地址。像这样的地址http://localhost/?act=xxx不会暴露后台绝对路径,甚至可以经常更改,不用改变太多代码。一个入口点文件也可以验证访问者的身份,比如一个网站后台,不是管理员就不允许查看任何页面。在入口点文件中就可以验证身份,如果没有登录,就输出404页面。
有了入口点文件,我就把所有非入口点文件前面加上了这句话:
<?php if(!defined('WWW_ROOT')) {header("HTTP/1.1 404 Not Found"); exit;} ?>
WWW_ROOT是我在入口点中定义的一个常量,如果用户是通过这个页面的绝对路径访问(http://localhost/register.php),我就输出404错误;只有通过入口点访问(http://localhost/?act=register),才能执行后面的代码。
使用预编译语句,避免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注入,这也是吴翰清最推荐的解决方案。
下面是使用mysqli的一些代码部分(所有的判断函数运行成功或失败的代码我都省略了,但不代表不重要):
?
在我的网站中并没有使用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方式来赞某篇文章。
<form action="http://localhost/?act=support" method="POST"> <input type="hidden" value="12" name="articleid"> <input type="submit" value="赞"> </form>
可以看到一个隐藏的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推荐使用的。
如果大家需要,可以到这里下载http://pan.baidu.com/s/1bnb8Zmf
好了,我能想到的,也是在实际运用中用到的东西也就这么多了。这也仅仅是我自己写代码中积累的一些对代码安全性的一个见解,如果大家还有更好的想法,可以和我交流。希望大家也能写出更安全的代码。
转载请注明来源:PHP安全把握整站的结构,避免泄露站点敏感目录
http://www.php1.cn/Content/PHP_AnQuanBaWoZhengZhanDeJieGouBiMianXieLuZhanDianMinGanMuLu.html
相关文章推荐
- 一个关于if else容易迷惑的问题
- PHP5.2.*防止Hash冲突拒绝服务攻击的Patch
- 深入理解PHP之匿名函数
- 谷歌 Project Zero 团队宣布新政策,漏洞披露前将有完整的 90 天缓冲期
- JSP/PHP基于Ajax的分页功能实现
- 关于PHP通过PDO用中文条件查询MySQL的问题。
- 什么是设计模式
- PHP数据库长连接mysql_pconnect的细节
- Php Installing An Expansion
- 春节长假安全手册
- 地震避险自救常识
- 路由器安全有关的目录
- 打造个性_安全的电脑系统图文教程2第1/2页
- 路由器内的安全认证
- 加强php的安全之一
- PHP+Apache在Windows 9x下的安装和配置