Mining XSS vulnerabilities in HTML5 mobile apps

Mining XSS vulnerabilities in HTML5 mobile apps

Now it is increasingly popular to develop mobile apps using HTML5. HTML5 is not only highly efficient in development, but also cross-platform and highly reusable in code. Zoho (the world's largest online software provider, headquartered in the United States) is an HTML5 email system with 13 million users. I plan to dig for their vulnerabilities.

Search for Html and Javascript code

First, I downloaded the APK from Google Play and opened it with the decompression software.

The assets folder contains many html files. html files and javascript files are much easier to read than java files.

After several times, I found that maildetail.html is used to display the mail content. Here, a vulnerability is very interesting.

After reading the code and understanding the code structure, we found that it called the setContent method:

function setContent(contentToSet,margin){    document.body.style.marginTop = margin + "px";    document.body.style.marginBottom = "10px";    setBaseURL();    document.getElementById('mailcontentid').innerHTML = "";    handleContentForMailThread($('mailcontentid'), contentToSet);    androidResponse();    }function handleContentForMailThread(contentEl,value) {    var ind = value.indexOf("<blockquote");// NO I18N    if(ind < 0) {    addContentToElement(contentEl,value);        return;    }    else    {        // removed 54 lines here for readability    }    }function addContentToElement(contentEl,value){contentEl.innerHTML = value;addListener();}

If you track the contentToSet variable (which should be the content of the email), you will find that no escape operation is performed on the data in javascript code. Therefore, if there is any escape or security operation, it can only be done on the server or in java code.

Determine whether the email content has been securely processed

The simplest way is to add the payload code unknown at the beginning of the setContent function, such as alert (contentToSet), and then package and re-sign the code.

I added the following payload to the apk package:

test<jukkhttp://test<jukk http://test%3Cjukk

The result is as follows:

The first two payloads are correctly processed, but the third payload (I previously encoded the data with a url) shows a <angle bracket.

It seems that there is a blacklist in the background. If there is enough time, these blacklists will certainly be bypassed, but I have no sense of manual fuzzing, so I have another path.

Reverse APK

I have never written an apk, so I decided to read webview-related code. When I found the code for passing data from java to html, I was taken to webView. loadUrl tripped, which obviously can execute javascript code:

webView.loadUrl("javascript：initialize(" + myNumber + ");");

Obviously, zoho uses code similar to the preceding one to display the previously encoded data correctly.

By using dex2jar to reverse the apk to A. jar file, I read these jar files using the JD-GUI and I searched for the setContent function (previously mentioned javascript function ),

this.webView.loadUrl("javascript：setContent(" + JSONObject.quote(this.content) + "," + i + ")");

As you can see, zoho uses similar code.

Summary

Zoho uses the webview. loadurl method to call the setContent method. What does this tell us? When uri is opened in this way, the javascript in it will be executed, and any pct-encode ugo code will be executed as normal code.

The following code is easy to understand.

// this line of code:location.href = 'javascript：setContent("%22-alert%281%29-%22")';// is the same as this:location.href = 'javascript：setContent(""-alert(1)-"")';

Obviously, you can execute any javascript code in the mail client by including the following payload in any part of the mail:

%22-alert%281%29-%22

Summary

A few days after I reported the vulnerability to zoho, they released a new version on Google Play, and I was notified that someone else had reported the vulnerability to zoho.

I think this vulnerability is very interesting. Many other apps may have many similar vulnerabilities. However, finding vulnerabilities in applications developed using HTML is more difficult than searching for vulnerabilities on the web. Let's dig holes together to save the world and make the Internet safer!