|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #68287 short_open_tag should not include <?=...?>
Submitted: 2014-10-22 16:17 UTC Modified: 2016-03-27 16:38 UTC
From: patchcord at gmx dot net Assigned:
Status: Wont fix Package: PHP options/info functions
PHP Version: 5.4.34 OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2014-10-22 16:17 UTC] patchcord at gmx dot net
In PHP Docs, there is stated that if 'short_open_tag=FALSE' this also covered  the shorthand <?=, but only prior to PHP 5.4.0. I am wondering why this thing has been got back and for what reason? Putting <?= ... ?> for echoing, in general, is a specific practice, and this is insecure for some cases, which I will try to describe below.

There are lots of so called "shell scripts" which are often included in binary files as PHP parts and later executed, causing websites for different illness. 

My current solution is a simple scanning of uploaded binary files for '<?php' strings inside. I suppose there is only a very small percent of binary files, which will contain '<?php' as the part of their original binary code. Even if so, there is no problem for me if such file wouldn't be uploaded.

Still, there are lots of binary files, having '<?' or '<?=' as their original parts, so it's impossible relay on scanning of those tags, 'cause they couldn't be the parts of the shell script.

Setting 'short_open_tag=FALSE', earlier, I have achieved that even if something binary is being uploaded, yet having '<?' or '<?=' inside, this will simply not execute. On the other hand, something which could be executed like '<?php' will not be allowed to upload. THIS protected the website with the uploaded files feature for a long time.

NOW, when '<?=' is allowed EVEN if 'short_open_tag=FALSE', this breaks the security, because shell scripts could adopt to this directive and 'echo' something functional. I've already seen this couple of times.

QUESTION: is there still a way to DISABLE '<?=', an if not, wouldn't be better to introduce an extra option which DISABLES this? For example, instead of just TRUE/FALSE, there could be:

short_open_tag = 0; //completely disables any tag except <?php incl. <?=
short_open_tag = 1; //disables <? but allows <?= and <?php
short_open_tag = 2; //allows all <?, <?php, <?=

I'm just not sure how many coders are truly up to using <?= in their scripts. Do you have the statistics? I think, allowing just <?php is suitable for all cases. But even if someone needs this or that, this could be re-configured... By now, it's strictly forced and it's a bit wrong.

Thanks for attention and hoping this option will be up in PHP again.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-03-27 16:38 UTC]
-Status: Open +Status: Wont fix
 [2016-03-27 16:38 UTC]
What you're doing there is very fragile. PHP has a number of different opening tags, <?php, <? and <?= being the best known ones. However there's also <% if asp_tags is enabled (you probably disabled it). And then there is <script language=php>, with a bunch of different quoting and whitespace variations. If you don't check for one of them, your checks are moot.

The proper solution to this problem is to ensure that uploaded files are never run as PHP code. They should not reside in a location served by the webserver and/or not have a file extension that is associated with PHP.

Closing as Won't Fix.
 [2016-03-28 17:59 UTC] patchcord at gmx dot net
It seems I've provided all possible infos why it is insecure, and earlier, it HAS BEEN developed that PHP script could not be executed if tags are just <? ... ?>. 

What you provided below, was just your personal opinion. No stats and no serious analysis of why this "feature" got back. You didn't need to describe it all, 'cause it's all known to experienced coders. But you didn't even go deeply into the problem and question I described.

Now I know latest versions of PHP are built up to private opinions of quite inexperienced staff. Thanks a lot.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Apr 13 17:01:24 2021 UTC