PHP 5.5 short_open_tag=on Security Hole?

Question

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 &

Answer 1

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.