Req #68287 [Com]: short_open_tag should not include <?=...?>

Edit report at https://bugs.php.net/bug.php?id=68287&edit=1 ID: 68287 Comment by: patchcord at gmx dot net Reported by: patchcord at gmx dot net Summary: short_open_tag should not include <?=...?> Status: Wont fix Type: Feature/Change Request Package: PHP options/info functions PHP Version: 5.4.34 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2016-03-27 16:38:21] nikic@php.net 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. ------------------------------------------------------------------------ [2014-10-22 16:17:06] patchcord at gmx dot net Description: ------------ 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68287&edit=1