[翻译]PHP安全小建议（下）

 　　近日比较关注PHP的安全问题，国内的许多开发者，特别是PHP初学者，很多时候仅满足功能是否实现，对安全的探讨浅尝辄止甚至漠不关心。这样的后果很严重，比如泛滥的SQL注入，甚至还有直接被下载数据库连接文件的……此文译自Cal Evans发表DevZone的系列专题：PHP Security Tip (安全建议/小窍门) 虽然不是最新文章，但提到的许多原则性的东西和经典的做法仍然是值得重视的，绝对是值得一读的好文章，借此抛砖引玉，希望能给大家一点帮助，建立良好的安全意识，了解必要的防范措施。 文中加入本人的理解和注释的地方已经注明，首次翻译，不当之处欢迎指出。谢谢 ! ——By Falcon

　　,原书共21个建议，这是翻译的下部。

    [翻译]PHP安全小建议（上）

　　------------------------------------------------------------------------------

　　PHP Security Tip #12

　　Cal Evans (editor) | 1 comment | Friday, March 16, 2007

　　We’ve talked about filtering, we’ve talked about validating, we’ve talked about filtering again. Filtering inputs into your application is an important concept and the pre-cursor to many good security practices. However, once you have the input filtered and validated you can’t simply sit back and relax. You have to stay vigilant when programming to ensure security throughout your application.

　　Filtering input gives some developers a false sense of security. They assume that since they;ve filtered the input, there’s no reason to worry. That may be true in some simple instances but in most complex applications, you have to constantly be aware of what you are using the input for. This is never more true than when using user input in the eval() command. That brings us to today’s tip:

　　Think carefully before using eval()

　　By using user-inputted values in an eval(), you are potentially giving a malicious user a gateway to your server. Even if your interface forces them to chose only predefined options, the call to your script can be spoofed and your script can potentially be used to execute commands on demand by people who want to do bad things.

　　Use eval() sparingly. When you do have to use it, make sure you filter and then validate the input. If there are other ways to accomplish the task then consider using them instead.

　　=C=

　　------------------------------------------------------------------------------

　　PHP安全建议#12

　　我们谈论过过滤，谈论过验证，让我们又再来讨论一下过滤。

　　过滤用户输入是个很重要的观念，也很多良好安全习惯的前导(pre-cursor)，然而，经过了过滤输入和验证处理之后，你还不能坐下来歇一会。在贯穿整个应用程序安全的编码中，你必须保持警惕。

　　过滤输入给某些开发者一种安全错觉，他们会武断地认为，既然已经过滤了输入 ，那就应该没什么理由再担心了吧。可能在一些简单的实例里确实如此，但在大规模的复杂应用中，你必须不断留心你使用该输入来做什么。尤其是在使用eval()命令下使用用户输入时，由此开始我们今天的建议：

　　在使用eval()前请谨慎。

　　在eval()里使用用户输入值时，你有可能给为恶意使用者进入你的服务器打开了大门。即使你的接口只允许他们选择预定义的选项，调用脚本时可能被进行了欺骗(spoofed)。你的脚本可能潜在地被利用来执行他们的请求命令，以此进行一些不良行为的。

　　谨慎地使用eval() ,当你必须使用它时，务必对用户输入经过过滤和验证处理。如果还有其他方法完成相同的任务，那么应该考虑用它们来代替。

　　------------------------------------------------------------------------------

　　PHP Security Tip #13

　　Cal Evans (editor) | 4 comments | Tuesday, March 20, 2007

　　Security is a mindset, not just something you do. It colors your application design as well as your coding. However, you also need to constantly monitor your production environment. That’s where selecting the right tool comes into play. I know I’ve mentioned PHPSecInfo before but I think this tool is important enough to warrant it’s own post.

　　PHPSecInfo is a great tool to use to keep an eye on your production environment. It was written by Ed Finkler of CERIAS, the Center for Education and Research in Information Assurance and Security at Purdue University. It is officially a project of the PHP Security Consortium. Here’s what the PHPSecInfo homepage has to say about itself.

　　PHPSecInfo provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.

　　If you need more info, here’s the link to a short interview with Ed talking about PHPSecInfo. Here is another link to the latest release notice for version 0.2.

　　As with all security measures, by itself it’s not the silver bullet. Used properly though, it can be part of a comprehensive solution.

　　------------------------------------------------------------------------------

　　PHP安全建议#13

　　安全是一种思想，而不只是一些你要做的事情，它会令应用程序的设计和编码增色(colors)不少。然而你还需要不断地监控生产环境，这是选择正确的工具投入工作的地方。我以前提到过PHPSecInfo ,我认为这个工具非常重要以致于我把它作为独立的一节来介绍。

　　PHPSecInfo 是一个用来监视生产环境的强大工具，它是CERIAS的Ed Finkler编写的，CREIAS是Purdue大学信息安全与保障教育研究中心的简称。(the Center for Education and Research in Information Assurance and Security at Purdue University.),是PHP安全协会的官方项目(PHPSecInfo威武!)，这是PHPSecInfo主页对其一些必要的说明：

　　PHPSecInfo提供一个等价的phpinfo()函数来报告PHP环境的安全信息，并提供改进建议，它目的不是取代安全开发的技术，也不对程序进行任何形式的编码或审核应用。但在使用多层面的安全手段时却是一个很有用的工具。

　　如果想了解更多信息，下面是一段Ed谈论PHPSecInfo的小采访的链接，还有另外一个链接，是最新发布的0.2版本的通告。

　　http://devzone.zend.com/node/view/id/1099

　　http://devzone.zend.com/node/view/id/1735

　　像所有安全措施一样，(PHPSecInfo) 就其本身，并非银弹(见建议#1的译注 )，但是适当使用，将会成为综合解决方案的一部分。

　　------------------------------------------------------------------------------

　　PHP Security Tip #14

　　Cal Evans (editor) | 2 comments | Wednesday, March 21, 2007

　　Almost any application running PHP on the back-end uses web technologies for it’s front end. Many developers who think hard on PHP security, don’t spend a thought on front-end security for their application. Here’s a tip to think long and hard about when building your HTML and Javascript.

　　Any data inside of a COOKIE can be potentially seen by others- restrict to a minimum

　　It’s a sad fact on today’s web but there are bad people out there. They want nothing more than for your application to leak sensitive data so they can exploit it. Make sure you look at the whole picture when evaluating the security of your application. This is very important when looking at what information you persist on the front end.

　　------------------------------------------------------------------------------

　　PHP安全建议#14

　　差不多所有PHP程序都是运行PHP作为后端，使用web技术作为前端，很多开发者对PHP安全思考了很多，却从来没想过它们前端应用的安全。这里的建议是：当你构造HTML和Javascript时，你应该思考得更长远和深入些。

　　任何保持在COOKIE里面的信息都有可能被其他人所看到——尽量把这些信息控制到最少

　　今天的web界有一个很悲哀的事实，有些不怀好意的人出没其间，他们只想让你的应用程序泄露敏感信息，然后破解它，当你评估应用程序的安全时，务必观察全局。非常重要的一点是看看你在前端保留了些什么。

　　------------------------------------------------------------------------------

　　PHP Security Tip #15

　　Cal Evans (editor) | 5 comments | Friday, March 23, 2007

　　As developers, most of us are very messy. I’ve worked on countless projects and at each either run across or left a trail of diagnostic files laying around. (info.php, test.php, doMe.php, etc.) These tiles, if found by someone with nefarious intent, can leak valuable information about your system.

　　Today’s Security tip is:

　　Don’t forget to purge temporary system diagnostic files.

　　It would be a shame to spend all that time securing your application only to leave info.php or worse yet, a “quick piece of code” in test.php that could potentially leak dangerous information about your system. Don’t help the ad guys any more than you have to.

　　=C=

　　p.s. Got a security tip? Post it! If it’s good enough we’ll share it with everybody else. Just log-in and click the contribute link in the upper right corner.

　　------------------------------------------------------------------------------

　　PHP安全建议#15

　　作为开发者，我们大部分的人都是非常肮脏的，我为无数项目工作过。每次都能发现或者留下一堆额外的诊断文件，随地乱放。像(info.php, test.php ,doMe.php等)，这些文件，如果被某个怀有不良企图的人发现，将很有可能泄露系统的有用信息。

　　今天的安全建议是

　　不要忘记清除临时的系统诊断文件

　　在清理危害你的应用的这些文件时你可能会感到惭愧，看到那些留下来的info.php或者更糟的，在test.php“一段快速代码片断",它们都会潜在地泄露关于系统的危险信息，不要再助那些发广告的家伙(ad guys)一臂之力了。

　　p.s. 你也有安全方面的小建议，把它发布出来吧，能和他人分享是一件再好不过的事了，只要登录并点击右上角的贡献按钮。

　　------------------------------------------------------------------------------

　　PHP Security Tip #16

　　sascha_leib | 1 comment | Monday, March 26, 2007

　　Keep Your Framework Up to Date

　　I have posted it before as comment, but since I believe that this is a very important issue, it might be worth a ‘security tip’ of its own:

　　Make sure any framework you are using is updated regularly.

　　This is especially important if you are working on a ‘one-shot’ client project. It is important to think about who is going to maintain the site if (or rather: when) a security patch is issued for any of the 3rd party files.

　　Usually, these sites are placed on a shared hosting site, and that means the provider is responsible for keeping PHP, database system, web server, etc. up to date – but they will probably not maintain the frameworks you have installed.

　　Using frameworks is generally a good idea – not only because they take a lot of the work away from you, but also because any potential security issue will (usually) quickly be dealt with.

　　On the other side, this means that security issues in these frameworks are very well documented – and it is all to easy for a malicious hacker to search for old versions of the framework in use, and exploit these problems.

　　I have seen many, many sites which are still using extremely old and outdated files – simply because there is nobody there to update it. And I’m talking about old PEAR installs (with known issues with the ‘Mail’ component) and worse!

　　------------------------------------------------------------------------------

　　PHP 安全建议 #16

　　保持框架的更新

　　我已经在之前的评论中发表过了，但鉴于我相信它是非常重要的话题，它有可能值得独立作为一个“安全建议”

　　务必经常更新任何你使用的框架。

　　如果你工作在"一次性"的客户项目上，这点尤其重要。很关键的是要考虑到，如果(或者当)第三方软件补丁发布的时候，由谁去维护这个站点。

　　通常这些网站是放在共享主机的站点上面的，这意味着供应商有责任为PHP，数据库系统和Web服务器保持更新。但他们不太可能维护你安装的框架。

　　一般来说使用框架是一件好事，不仅因为它可以为减少大量的工作，而且任何潜在的安全问题将(通常)会得到快速处理。

　　另一方面，这也意味着这些框架的安全问题很好地被文档化了，同时也方便了不怀好意的黑客搜索系统使用框架

　　的旧版本并通过这些安全问题进行爆破。

　　我看过很多很多的网站仍然在使用一些非常老的、过期的文件，仅仅是因为没有人去更新它，还在使用旧版 的PEAR 库(其中广为人知的Mail组件安全问题) 的网站会更糟!