MySpace threats go mobile!

Two new sections have been launched in the last month. There's
still no care about user's security

Convergence is the word.

On December 2007, MySpace launched a mobile version of the portal, available
at the URL: http://mobile.myspace.com.

The portal is completely written in xhtml and is accessible from most wap
enabled mobile devices.

I suspect that business opportunity (the "rush" for launching the service
asap) has turned MySpace programmers completely blind...

There's no other explanation for this huge logical flaw in the mobile
portal.

Login at mobile.myspace.com and browse to the Modify Profile
section.

Here you can enter in the
profile form any HTML/JS code you like. As far as you stay on the mobile
site, there's no chance to get your code executed, as all the profile data are
displayed with html
entities encoding.

Well... now try to login to the standard Web portal (www.myspace.com) and
check your profile: you are
XSSed!

The profile data are loaded (from the DB I suppose) and no filtering is
performed!

So, editing your own profile on mobile.myspace.com turns to be the quickest
and simplest way to evade MySpace.com anti-XSS filters.

A simple <script>whateverJsCodeYouLike</script> inputed in the
profile fields leads to a permanent XSS that can be abused for:

cookie stealing

phishing

defacing

Simple and effective.

The mobile.myspace domain doesn't "trust" authentication done on myspace.com
so, even if you are already logged on the web portal, you need to
re-authenticate on the mobile domain. After proper authentication the site
issues a cookie called uwtbr that seems to be some kind of salted hash
of the user credentials.

This behaviour, togheter with Same Origin Policy constraints, limits the
chance to leverage this XSS vuln in order to create a worm.

MySpace has recently launched a new smart video section called MySpaceTV.
It's a YouTube-like service that allows users to upload/share videos.

The whole service is based on a flawed swf player available at the
url: http://lads.myspace.com/videos/vplayer.swf

After just checking the swf file with SWFIntruder you can find a LOT of uninitialized variables: there's no really need
to run XSS fuzzing in order to understand that "URI" parameter could be
quite dangerous and that "a" parameter stands for "autoplay".