Very recently there has been a new paper about what the authors call JavaScript Hijacking. It is about an analysis of several JavaScript frameworks for a cross domain data retrieval vulnerability through the usage of the <script> tag. The paper comes to the conclusion that in nearly all JavaScript frameworks that work with JSON encoded data, the data can be retrieved cross domain via the <script> tag.

While some might consider this news and others do not, the authors very clearly write in their paper that this kind of vulnerability is already discussed in several places. However some malicious bloggers (previous link was wrong) claim that Fortify claims to have found a new class of web-based attacks. Other bloggers, like Chris Shiflett try to disinform people that this is just a CSRF vulnerability used for information disclosure and that you cannot protect from it via the Referer HTTP header because it is spoofable by Flash.

First of all the problem Fortify describes is not bound to CSRF attacks, because it simply describes how data can be retrieved with the <SCRIPT> tag. The described problem is not the possibility to do the request, but the problem that it is possible to retrieve a cross domain answer. And because of this the statement that checking the Referer header is not a possible safeguard because it can be spoofed by for example Flash is completely bogus. It is bogus because Flash has nothing todo with <SCRIPT> tags. And even if you can perform a Flash attack with a spoofed (isn't that problem fixed in latest Flash anyway) Referer header you can still not read the response and that is what the Fortify paper is all about.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve. You will find a lot of input filters like the following one.

<?php
   $clean = array();
   if (preg_match("/^[0-9]+:[X-Z]+$/", $_GET['var'])) {
      $clean['var'] = $_GET['var'];
   }
?>

Quite common way to filter incoming data, isn't it?

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject. However the real meaning, as it is even documented in the PHP manual is that $ means the end of the subject OR not the real end but nearly, only followed by a single '\n' linebreak. This means that the following request will also pass the filter.

   http://server.tld/index.php?var=012345:XYZ%0a

In several circumstances a newline character can be dangerous. For example when you want to stop HTTP Response Splitting or Email Injection attacks. To correct the above regular expression it is necessary to add the D modifier to it that changes the meaning of the $ specifier to really mean the end of the subject. Here is the corrected example.

<?php
   $clean = array();
   if (preg_match("/^[0-9]+:[X-Z]+$/D", $_GET['var'])) {
      $clean['var'] = $_GET['var'];
   }
?>

I hope this tip helps getting rid of all these wrong filters once and for all. People using ext/filter should prepare for a recompile, too.

PS: The regular expression is now more complicated to make this post easier to understand