Google Video Security Flaw: FALSE; MySpace Flaw: Confirmed

Tell your friends!

Tamar Weinberg writes a post declaring that “Google Video Flaw Raises Privacy Concerns By Exposing Usernames and Passwords“.

Nice linkbait, but completely false. The real weight of this flaw lies solely on MySpace (I know, there are apparently no security issues with MySpace, but I digress). In fact, if you examine the headers of a MySpace login, it is obvious to see that MySpace itself is transmitting username and password in plaintext in the headers.

Most people don’t look at headers. Why should they? They are the communication vehicles of browsers and server and not users. However, an examination of these headers by sleuthful individuals can find out all kinds of useful information.

Let’s look at the MySpace header that contains the username and password:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
http://login.myspace.com/index.cfm?fuseaction=login.process&MyToken=c7fd399e-2c28-4615-889e-dbf5c2cea71b

POST /index.cfm?fuseaction=login.process&MyToken=c7fd399e-2c28-4615-889e-dbf5c2cea71b HTTP/1.1
Host: login.myspace.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://myspace.com/
Cookie: MSCulture=IP=208.54.95.129&IPCulture=en-US&PreferredCulture=en-US&Country=US&timeZone=0&ForcedExpiration=0&USRLOC=QXJlYUNvZGU9MCZDaXR5PSZDb3VudHJ5Q29kZT1VUyZDb3VudHJ5TmFtZT1Vbml0ZWQgU3RhdGVzJkRtYUNvZGU9MCZMYXRpdHVkZT0zOCZMb25naXR1ZGU9LTk3JlBvc3RhbENvZGU9JlJlZ2lvbk5hbWU9; NGUserID=a2825a9-4920-1181671731-2
Content-Type: application/x-www-form-urlencoded
Content-Length: 165
Login=&email=myemail%40hotmail.com&password=mypassword&ctl00%24Main%24SplashDisplay%24ctl01%24loginbutton.x=0&ctl00%24Main%24SplashDisplay%24ctl01%24loginbutton.y=0

The interesting part is right at the bottom where, if you look, my (now fake) username and password are displayed.

Update: To be fair, Facebook is guilty as charged as well.

Update 2: As does many other pieces of software. This highlights a deficiency in the HTTP protocol. HTML Password fields should be encrypted before transmission. Why is this not the case? What good reason can anyone give me why this should not have been fixed in, oh, 1996?

  • http://buzznetworker.com kevin

    Thanks for the link, I will take it even though it is dripping in sarcasm. :)

  • http://buzznetworker.com kevin

    As far as it not being fixed years ago I blame Y2K and Al Roker. They are the easiest scapegoats in this situation.

  • http://gregword.com Greg Gershman

    You’re mixing up HTML forms and HTTP protocol. There are secure ways of transmitting passwords over HTTP (or, more correctly, HTTPS), but in the body of a form is not one of them.

  • http://mynetmarketingland.com/blog Franck Silvestre

    Ok, but what is the problem with this? I didn’t get it.

  • http://www.kinggary.com/ Gary King

    I would have thought they encrypted the passwords. That’s what I do by default on all my own apps, so that the server ever knows the actual password.

Data provided by Marvel. © 2015 MARVEL