Skip to main content

U-XSS in OperaMini for iOS Browser (0-Day) [CVE-2019-13607]


TL;DR: The latest version (16.0.14) of Operamini for iOS browser is affected by an Universal-XSS vulnerability which can be triggered by performing navigation from target domain to attacker controlled domain. When attacker controlled domain returns "javascript:code_here" in "location" header then browser executes the javascript code in the context of target domain instead of attacker domain. This vulnerability is yet not fixed by Opera team. 

Update [15 July 2019] : CVE-2019-13607 is assigned to this vulnerability.

So while playing with Operamini browser I noticed that when a navigation to "javascript" protocol occurs via "location" header then browser executes the provided javascript code.

For example if the value of "location" header is "javascript:alert()" then javascript code "alert()" gets executed by the browser. Normally browsers prevent navigation to "javascript:" URLs initiated via "location" header however Operamini did allow it and happily executed the provided javascript which is unbelievable. 

Allowing javascript code execution was just a beginning, the more worst thing was that the browser was executing the javascript code in the context of the domain from where the navigation was initiated.

So if you can post a link to any website then you can execute javascript in the context of that website by simply performing the redirect to "javascript" protocol with your javascript code via "location" header. Also you can use an open redirect vulnerability to initiate the navigation from the target domain to execute your javascript in its context.

I have setup a demo page here : http://rakeshmane.com/secret.html

 In demo page "secret.html" there's a link which redirects to "http://bounters.team/test_red.php?url=javascript:alert(document.body.innerHTML)" when clicked. The script "test_red.php" responds with value "javascript:alert(document.body.innerHTML)" in "location" header. The browser then executes the code "javascript:alert(document.body.innerHTML)"  in the context of domain "rakeshmane.com" because the navigation was initiated from that domain. This way an attacker can executed javascript code in the context of any domain if he can post links to that web application or if there's an Open Redirect vulnerability in that web application.

 Let's look at real world example now, suppose if an attacker wants to execute javascript in the context of "google.com" then he can send the victim a link to "https://www.google.com/url?q=http://bounters.team/test_red.php?url=javascript:alert(document.domain)", once victim clicks on the link in Operamini browser the javascript will execute in the context of "google.com".

VIDEO POC :

 1. Demonstrating U-XSS by executing "document.domain" in Google.
2. Demonstrating U-XSS by fetching Google homepage.


Irresponsible Disclosure: I have reported this vulnerability to Opera at "https://security.opera.com/report-security-issue/" on 12th June, however apart from acknowledgement email I did not get any other information from them. "Our team is reviewing the report" is the only update I got so far from them so probably they are not interested in fixing this vulnerability anytime soon. Opera team is very slow and does not maintain any transparency and not really serious about the security of their mobile browsers. So I would totally recommend to move to other secure browsers if you are using Operamini. 

 [Disclaimer : This post is only for educational purpose and I do not encourage anyone to misuse the information given in this post]

[THE END]

Comments

Post a Comment

Popular posts from this blog

JSP ContextPath Link Manipulation - XSS

This post is about how to manipulate resource links of HTML elements (script, img, link, etc) when getContextPath  method is used to obtain base path of resources. With the ability to manipulate links you can do XSS, CSS Injection, etc. Basically we are going to use path parameters to manipulate context path such that links would point to attacker's domain. There's a good blog that talk about the similar issues :  https://superevr.com/blog/2011/three-semicolon-vulnerabilities However this post is more about manipulating context path to hijack resource links of HTML elements .  So let's have a look at a simple JSP page ( test.jsp ) Ref :  https://www.roseindia.net/jsp/request-getcontextpath.shtml This page just loads some resources like script, image, css and that's it. It doesn't take any direct input from user but it is using value returned by r equest.getContextPath() as base path to resources link. What can we do here? Let's try...
1 comment
Read more

Xssing Web Part - 2

Xssing Web With Unicodes Hello friends,  This is the second part of "Xssing Web". In this post I would show how to abuse unicodes to bypass XSS filters.  BTW if you want to check previous part click here . Note : If you think there are any mistakes in this post then kindly mention it in comments. I have developed several XSS challenges to show how unicodes can be used to bypass filters. If you want to try those challenges first then click here , get back here if you couldn't solve any. Abusing Unicode : So what is Unicode? -> Unicode is nothing but the encoding standard. It  defines  UTF-8 ,  UTF-16 , UTF-32 , etc encodings. 1) UTF-8 : Characters Size : 1 byte to 4 byte Example : Character "A" => 0x41 Character "¡"  => 0xC2 0xA1 Character "ಓ" => 0xE0 0xB2 0x93 Character "𪨶" => 0xF0 0xAA 0xA8 0xB6 2) UTF-16 : Character Size : 2 byte However in UTF-16 there are two...
5 comments
Read more