PHP 5.5 short_open_tag =关于安全漏洞? [英] PHP 5.5 short_open_tag=on Security Hole?

问题描述

我已经升级到PHP5.5，并在 PHP.ini 中现在升级为short_open_tag=off，我认识到这一点，因为某些文件由于<?而不是<?php而无法运行. /p>

现在有两种解决方案可以搜索任何php文件，并将open标签更改为<?php或激活short_open_tag=on

第二个选项是否存在安全性问题?

解决方案

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

首先让我们制定规格.在PHP 5.4和更高版本中，short_open_tag=on指令适用于除<?=以外的所有短标签-echo标签. 通常，由于可移植性，在整个代码中使用短标签被认为是不好的做法.我个人现在使用短标签. 从PHP 5.4和> = 5.4开始，短回显标记<?=始终可用，不受short_open_tag ini指令的影响.我认为，将回声标签与其他标签分开的决定是一个很好的决定.

实际上 PSR标准提出了这一建议.所以: PSR-1 建议仅使用<?php ?>或<?= ?>(回显短标签)-并且没有其他变体，以及 PSR-2 建议不要关闭仅PHP文件中的标记.这可能看起来很奇怪，但是有时在您的代码中可能会出现无法追踪的错误，因为在打开括号之前或在右括号之后有一个空格('')字符.这是一个众所周知的问题.我坚持这两种做法，因为在旧项目中使用不同的标签，因此一切都变得非常错误.

这都是从哪里开始的?

在PHP成立之初，人们就开始意识到PHP标记与XML和ASP的标记冲突.是的，您可以将<% //code here %>用作打开/关闭标签. 然后决定PHP将使用<?php ?>来区别于XML和ASP-一种PHP代码的顶级命名空间. 实际上，引入ASP标记是一种轻松的方式，以简化ASP开发人员对PHP的采用.

ASP标记由asp_tags ini指令处理，应该将其关闭.

再次-短标签的辩论一直在进行，这就是为什么现在短标签和短回声标签之间存在分隔的原因.我认为这是一件好事.只需替换旧代码中的所有短标签即可.

现在有关安全性.

您唯一需要担心的情​​况是，当您有一些用户输入最终以某种方式通过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() 或 ord() 或任何其他字符串操作函数.

防止此类攻击的最佳方法是阻止eval()执行.您应该可以通过 disable_functions ini指令.当然，解析您的代码！还要禁用eval().

在像Wordpress这样的系统中很难注意到这种类型的攻击，该系统在DB中存储了很多东西，其中大多数都是不必要的.我个人已经看到以两种方式之一对网站(不是我维护的:D)进行了这种代码注入:

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

希望这会有所帮助. 因此，请开始遵守 PSR标准.

• 除了回声标签<?=
，请勿使用简短标签
• 禁用ASP样式的标签
• 提防代码注入.

I've upgraded to PHP5.5 and in the PHP.ini now short_open_tag=off and I recognized this because some files are now not running because <? instead of <?php.

Now there are two solutions scouting for any php file and change the open tag to <?php or activate short_open_tag=on

Is there any security problem with the second option?

解决方案

Not a direct security vulnerability but it could become one given the proper conditions.

First off let's specs standards. In PHP 5.4 and higher the short_open_tag=on directive applies to all short tags except <?= - the echo tag. Generally it is considered that using short tags all over your code is a bad practice because of portability. I personally do now use short tags. Since PHP 5.4 and >= 5.4 the short echo tag <?= is always available and not affected by the short_open_tag ini directive. I consider this decision to separate the echo tag from the others a good one.

Actually the PSR Standards suggest this. So: PSR-1 suggests to only use <?php ?> or <?= ?> (echo short tag) - and no other variations, and PSR-2 suggests to not close the tags in PHP-only files. This may seem strange but sometimes there could be untraceable errors in your code because of a single space (' ') character just before your opening or just after your closing bracket. This is a well known issue. I adhere to both practices as I have seen it all go very wrong because of different tags usage in old projects.

Where did this all begin?

Back in the early days of PHP people started realizing that the PHP tags conflict with those of XML and ASP. Yes you can use <% //code here %> as a open/close tag. Then it was decided that PHP would use <?php ?> as to distinguish itself from XML and ASP - kind of a top-level namespace for PHP code. Actually the ASP tags were introduced as a comfortable way to ease adoption of PHP by ASP developers.

ASP tags are handled by the asp_tags ini directive and they should be off.

Again - the debate for the short tags was held and that is why now there is a separation between short tags and the short echo tag. I consider this a good thing. Just replace all short tags in your legacy code.

Now about security.

The only case you should worry about is when you have some user input that somehow ends up going through the PHP interpreter. You will need to strip:

• Normal PHP tags
• Short PHP tags
• Short Echo tags
• ASP style tags
• Byte-shifted code injection
• Anything that has <script language="php"></script>

This last portion - <script language="php"></script> - is very important since it is not being used today (and we're better off without it) but as far as I remember it is still supported by the PHP interpreter. So anything between that HTML script tag will be interpreted as PHP. All this is very well explained here.

What the hell is Byte-shifted code injection?

It's kinda hard to explain but the basic idea is it is obfuscated code injection. So if an attacker somehow is able to inject some PHP code and he/she does not want the maintainer/developer to immediately identify it he could do something like the folowing:

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

The idea is that the "blob of a sting" is a php code string but byte shifted so it is obfuscated. In my example the eval() will receive echo "you are attacked and your website has been taken over". I am using str_rot13() as it is easy to obfuscate a string back and forward, but this could be a custom function based on chr() or ord() or any other string manipulation functions.

The best way to prevent such an attack is to prevent eval() execution. You should be able to do this through the disable_functions ini directive. Parse your code of course! But also disable eval().

This type of attack can be really hard to notice with systems like Wordpress, which store a lot of stuff in the DB, most of them unnecessarily. I've personally seen such code injection done to websites (not those I maintained :D) in one of two ways:

• DB corruption (Possible when the application stores something that gets interpreted)
• Direct PHP source file corruption - This is much easier to analyze - just diff it against the latest version in a repository or compare it to some source backUp (again via diff).

Hope this helped. So please start adhering to the PSR Standards.

• Do not use short tags except for the echo tag <?=
• Disable ASP-style tags
• Watch out for code injections.

这篇关于PHP 5.5 short_open_tag =关于安全漏洞?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！