12

我现在已经升级到 PHP5.5 并且在PHP.ini中short_open_tag=off并且我认识到了这一点，因为有些文件现在没有运行，因为<?而不是<?php.

现在有两种解决方案搜索任何 php 文件并将打开标记更改为<?php或激活short_open_tag=on

第二种选择是否存在安全问题？

4

1 回答 1

24

不是直接的安全漏洞，但在适当的条件下它可能会成为一个安全漏洞。

首先让我们来规范标准。在 PHP 5.4 及更高版本中，该short_open_tag=on指令适用于所有短标签，除了<?=echo 标签。通常认为，由于可移植性，在整个代码中使用短标签是一种不好的做法。我个人现在确实使用短标签。自 PHP 5.4 和 >= 5.4 起，短回显标签<?=始终可用，不受short_open_tagini 指令的影响。我认为将回声标签与其他标签分开的决定是一个很好的决定。

实际上，PSR 标准表明了这一点。所以： PSR-1建议只使用<?php ?>or <?= ?>(echo short tag) -而没有其他变体，而PSR-2建议不要关闭 PHP-only 文件中的标签。这可能看起来很奇怪，但有时您的代码中可能会出现无法追踪的错误，因为在您的开始之前或在您的右括号之后有一个空格 (' ') 字符。这是一个众所周知的问题。我坚持这两种做法，因为我看到这一切都非常错误，因为旧项目中使用了不同的标签。

这一切是从哪里开始的？

早在 PHP 的早期人们就开始意识到 PHP 标记与 XML 和 ASP 的标记冲突。是的，您可以<% //code here %>用作打开/关闭标签。然后决定 PHP 将使用<?php ?>as 来区别于 XML 和 ASP——PHP 代码的顶级命名空间。实际上，引入 ASP 标签是为了方便 ASP 开发人员采用 PHP 的一种舒适方式。

ASP 标记由asp_tagsini 指令处理，它们应该是关闭的。

再次 - 对短标签进行了辩论，这就是为什么现在短标签和短回声标签之间存在分离。我认为这是一件好事。只需替换旧代码中的所有短标签。

现在谈安全。

您应该担心的唯一情况是当您有一些用户输入以某种方式最终通过 PHP 解释器时。您将需要剥离：

  • 普通 PHP 标签
  • 简短的 PHP 标签
  • 短回声标签
  • ASP 样式标签
  • 字节移位代码注入
  • 任何有<script language="php"></script>

最后一部分 - <script language="php"></script>- 非常重要，因为它现在没有被使用（没有它我们会更好），但据我所知，PHP 解释器仍然支持它。因此，该 HTML 脚本标记之间的任何内容都将被解释为 PHP。这一切在这里都得到了很好的解释。

字节移位代码注入到底是什么鬼？

这有点难以解释，但基本思想是它是混淆代码注入。因此，如果攻击者能够以某种方式注入一些 PHP 代码并且他/她不希望维护者/开发人员立即识别它，他可以执行以下操作：

$smth = 'rpub "lbh ner nggnpxrq naq lbhe jrofvgr unf orra gnxra bire";';
eval(str_rot13($smth));

这个想法是“刺痛的斑点”是一个php代码字符串，但字节移位了，所以它被混淆了。在我的示例中，eval()将收到 echo "you are attacked and your website has been taken over". 我正在使用str_rot13()，因为它很容易前后混淆字符串，但这可能是基于chr()orord()或任何其他字符串操作函数的自定义函数。

防止此类攻击的最佳方法是阻止eval()执行。您应该能够通过disable_functionsini 指令执行此操作。当然解析你的代码！还要禁用eval().

这种类型的攻击对于像 Wordpress 这样的系统来说真的很难注意到，它们在数据库中存储了很多东西，其中大部分都是不必要的。我个人已经看到通过以下两种方式之一对网站（不是我维护的那些：D）进行此类代码注入：

  • 数据库损坏（当应用程序存储被解释的内容时可能）
  • 直接 PHP 源文件损坏 - 这更容易分析 - 只需diff将其与存储库中的最新版本进行比较，或将其与某些源备份进行比较（再次通过diff）。

希望这有帮助。所以请开始遵守PSR 标准。

  • 不要使用除了 echo 标签之外的短标签<?=
  • 禁用 ASP 样式标签
  • 注意代码注入。
于 2014-03-24T08:41:07.737 回答