从5个方面全面解析PHP的糟糕设计

C之类的东西守护以避免直接加载. 版本控制系统的文件(如 .svn) 需要保护. 使用 mod_php , 使得文件系统的所有东西都是潜在的入口; 使用应用服务器, 仅有一个入口, 并且仅通过 URL 控制调用与否.>> 你不能无缝的升级那堆以 CGI-style 运行的文件, 除非你想要应用崩溃和出现未定义行为, 当用户在升级的间歇期点击你的站点时.>> 尽管配置 Apache 运行 PHP 很"简单", 仍然会有一些陷阱. 而 PHP 文档建议使用 SetHandler 使得 .php 文件以 PHP方式运行, AddHandler 看起来运行良好, 然而事实上会有问题.当你使用 AddHandler, 你在告知 Apache "以 php 执行它" , 这是一个可能的处理 .php 文件的方式. 但! Apache 对文件的扩展名不这样认为. 它被设计为能支持如, index.html.en 这样的文件. 对于 Apache , 文件可以同时具有任意数量的扩展名.猜想, 你有个文件上传的表单, 存储一些文件到公共目录中. 确保没人能上传 PHP 文件, 你仅仅检查文件不能有.php 扩展名. 所有的攻击需要做的只是上传以 foo.php.txt 命名的文件; 你的上传工具不会看出问题, Apache 会认为它是个 PHP, 它会很高兴的执行.这里不是 "使用原始文件名" 或 "没有更好的验证"导致的问题; 问题是你的web服务器要被配置用来运行任何旧代码, 使得PHP "容易部署". 这不是理论上的问题; 我已发现很多实际的站点有类似的问题了.缺失的特性我认为所有这些都是以构建一个Web应用为中心的. 对PHP看起来很合理, 是它的销售卖点之一, 它是 "Web语言", 理应有它们.>> 无模块系统. PHP就是模版.>> 无 XSS 过滤器. htmlspecialchars 不是 XSS 过滤器.>> 无 CSRF 保护. 你必须自己做.>> 无通用标准的数据库API. 像PDO这类东西不得不包装每个特定数据库的API, 分别抽象不同部分.>> 无路由系统. 你的站点结构就是你的文件系统结构.>> 无认证或授权.>> 无开发服务器.>> 无交互调试模式.>> 无一致的部署机制; 仅仅"拷贝所有文件到服务器中".安全 语言边界PHP的蹩脚安全机制可能会放大, 因为它利用某语言拿出数据, 又把它转存到另一个中. 这是个坏注意. "<script>" 可能在SQL中意味着什么都不是, 但在HTML中就很是了.让情况更糟糕的是通常有人哇哇喊到 "你的输入要消毒". 那完全错误; 你不可能有什么魔法使块数据完全"干静". 你需要做的就是对语言说: SQL使用占位符, 进程孵化使用参数列表, 等等.>> PHP公然鼓励 "消毒": 有个数据过滤扩展可以做到.>> 所有的 addslashes, scripslashes, 和其它的 slashes相关的东西都是废物, 毫无用处.>> 我只能告诉你这么多, 无法安全的孵化进程. 你仅能通过shell执行字符串. 你的选择是疯狂的转义, 并希望默认的shell使用正确的转义, 或手动的 pcntl_fork_exec 和 pcntl_exec.>> 所有的转义命令和转义参数存在大致相同的描述. 注意在Windows中, 转义参数不工作 (因为它假设成 Bourne shell 语议), 转义命令仅仅用空格替换一堆标点符号, 因为没人能搞清楚 Windows 命令转义行为 (它可能默默的破坏你试图做的任何事情).>> 原始的内建 MySQL 绑定, 仍然广泛使用, 它无法创建 prepared statements.直到今天, PHP 文档关于SQL注入的建议还是让人抓狂的做如类型检查, 使用sprintf 和 is_numeric, 在每个地方手动的使用mysql_real_escape_string , 或在每处手动使用 addslashes (这个"可能更有用"!) 这样的实践. 并没有提到 PDO 或 参数化, 除了在用户评论中有点线索. 至少在两年以前, 我就有具体的向 PHP dev 抱怨过了 ,