PHP在安全上需要注意的地方
PHP是一种强大并且灵活的工具。而这种强大和灵活源于第三方库中那些各式各样的框架。每一个库都有他们唯一的一种数据输入特征。数据在传递过程中可能是安全的也可能不安全。
近期一个非常流行的网络蠕虫——NeverEverSanity是利用了phpBB这个流行的论坛程序上的一个输入判断的错误。在highlighting代码处没有对输入的UNICODE代码进行正确性检查。（译注：这里原文为“Their highlighting code didn't account for double-urlencoded input correctly.”经过几次修订，最终翻译为这样。但是依然感觉不是特别正确。）对于别有用心的用户输入的数据没有进行正确的判断造成执行任意PHP语句或向文件系统写入文件的可能，这将你带来潜在的安全问题。尽管很多人对于当前PHP的一些安全补丁和NeverEverSanity蠕虫利用的漏洞混为一谈，但是这个蠕虫实际上并没有给PHP在安全问题上带来任何影响。
当我们讨论网络应用的安全问题时，我们有两个方面需要考虑：远程和本地。每一种远程的攻击当采取了仔细的输入判断后都是可以避免的。如果你写了一个要求用户填写用户名和年龄的程序，检查以便确认你得到的字符是你期望的。同时也要保证数据量不会造成你在后台存储数据或者向某些函数传递这些数据的时候造成溢出。另一种不同的远程攻击是一个用户输入了一些javascript脚本，而在下一个用户浏览的时候这些脚本被客户端浏览器执行。对于多数我们所知道的本地攻击是发生在虚拟主机上的open_basedir或者“安全模式”问题（译注：请参考PHP手册第24章“安全模式”的内容）。这两个特征本意是为了向系统管理员提供便利，所以绝对不应该被使用在完整的安全框架中。可以使用各种欺骗方法通过应用在PHP的第三方库来访问本地文件，这样就没有讨论安全性的可能。比如利用Oracle和Curl扩展库来访问本地文件的。对不开源的第三方Oracle扩展库做简单的修改是很困难的，这才是PHP真正无法做到的。
当你拥有一套完全由PHP编写的简单的“安全模式”和open_basedir扩展就足以阻止那些别有用心的人，但是对于多用户的WEB服务器来说，还是应该从系统级别上来讨论安全这个问题。比如每个用户都有自己的用户名并且都被限制在自己可以访问的文件系统内进行访问。当然更好的办法是使用从物理上独立的服务器。当你和其他你并不信任的人共享同一个服务器的时候你必须意识到你永远无法做到无懈可击的安全。
-----------------------
译后感
很久没有认真的去翻译点东西了，对于英文本来就不太好的我来说有点生疏了。这篇文章不长，也没有涉及到很具体的技术或者概念。但是其中有几点还是可以借鉴的。
对于语言的安全性问题，进几年来讨论得越来越热闹。难道PERL、PHP、JAVA或者C#都不如他们的前辈比如C、C++或者更老一些的汇编安全么？本文给出了一个很好的答案：语言本身是安全的，只是你该如何去使用它的问题。灵活性所带来的问题就是安全，这就如同麻醉药被滥用就变成毒品一样。所以当我们指责XX语言有安全漏洞，或者XX系统不够安全的时候，我们是不是首先应该考虑如何在现有的基础上编写更加安全的程序。而不是让语言的灵活性变成一些别有用心的人的大门。对于直接面向语言的程序工匠们来说或许这比期待着出现某个比现有语言更加安全的、灵活的、易用的语言要来得更加切合实际一些。
当你拥有一套完全由PHP编写的简单的“安全模式”和open_basedir扩展就足以阻止那些别有用心的人，但是对于多用户的WEB服务器来说，还是应该从系统级别上来讨论安全这个问题。比如每个用户都有自己的用户名并且都被限制在自己可以访问的文件系统内进行访问。当然更好的办法是使用从物理上独立的服务器。当你和其他你并不信任的人共享同一个服务器的时候你必须意识到你永远无法做到无懈可击的安全。
-----------------------
译后感
很久没有认真的去翻译点东西了，对于英文本来就不太好的我来说有点生疏了。这篇文章不长，也没有涉及到很具体的技术或者概念。但是其中有几点还是可以借鉴的。
对于语言的安全性问题，进几年来讨论得越来越热闹。难道PERL、PHP、JAVA或者C#都不如他们的前辈比如C、C++或者更老一些的汇编安全么？本文给出了一个很好的答案：语言本身是安全的，只是你该如何去使用它的问题。灵活性所带来的问题就是安全，这就如同麻醉药被滥用就变成毒品一样。所以当我们指责XX语言有安全漏洞，或者XX系统不够安全的时候，我们是不是首先应该考虑如何在现有的基础上编写更加安全的程序。而不是让语言的灵活性变成一些别有用心的人的大门。对于直接面向语言的程序工匠们来说或许这比期待着出现某个比现有语言更加安全的、灵活的、易用的语言要来得更加切合实际一些。