Abusing HTTP Status Codes To Expose Private Info 133
An anonymous reader writes "Here's a neat technique for testing if people are logged into other websites. Examples for Facebook, Twitter, GMail and Digg are provided." Like we needed more reasons to use the Chrome incognito function.
HTTP 502 - Service temporarily overloaded (Score:3, Informative)
Yes, that link is really neat!
HTTP 502 - Service temporarily overloaded
Re:And let's not forget... (Score:2, Informative)
Half the text is cropped by an overhanging left-menu if I use my normal text size. Gah!
Re:HTTP 502 - Service temporarily overloaded (Score:4, Informative)
Slashdotted already? Damn!
Try Google's cache http://webcache.googleusercontent.com/search?oe=UTF-8&hl=pt&q=cache:kZYcDFibjHcJ:https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information [googleusercontent.com]
The idea behind it... (Score:5, Informative)
The technique involves using Javascript to load an image only available when logged in to one of these services, and checking the HTTP status code returned.
Doesn't seem to be a ton of potential for abuse, but I suppose it's somewhat privacy-related.
The cached version (Score:4, Informative)
Re:HTTP 502 - Service temporarily overloaded (Score:4, Informative)
I believe you're supposed to abuse the HTTP error code somehow to get the content.
Corel Cache [nyud.net] also works.
How it works (Score:5, Informative)
For GMail, he added an image to his own GMail account, which he set to "visible for everyone". On his own site he added an invisible img and tries to access the image in his GMail account. He then triggers a javascript function depending on the outcome of the img inclusion (onload or onerror), so he can make the decision, if the visitor of his website is logged in to GMail.
For Facebook, Twitter and Digg he uses http status codes. He tries to access some URL (https://www.facebook.com/imike3) via javascript and depending on the status code he gets, he can decide whether you are logged in or not. This attack doesn't work with IE or Opera, because they do not trigger the onload/onerror events when receiving invalid js.
Re:And let's not forget... (Score:3, Informative)
You could write your own CSS or get an existing one [userstyles.org]
Re:The idea behind it... (Score:4, Informative)
Looks like you've just rediscovered the idea of cross-site scripting.
Wikipedia says:
"Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. "
Re:The idea behind it... (Score:3, Informative)
Precisely why a lot of discussion boards do not allow images in their signatures, especially third-party images. Also why so many companies used to offer "free counters" and "enhanced email with images" (a' la IncrediMail) and whatnot as long as they were served from THEIR site. You can collect a lot of information about users of a site without the complications of having to compensate the site owners or having them cooperate with you.
Ho hum (Score:2, Informative)
I wouldn't call this status code abuse (Score:2, Informative)
This is a javascript thing, not a problem with HTTP result codes. And a cookie problem too.
The idea here is that your page offers a script to the user, the user elects to execute this script with his own permissions, and the script requests resources from some other website and either fails or succeeds, and that success/failure implies certain facts about the user.
But when you describe it like that, does the fact that success/failure is detected, really look like the dangerous and scary part, or do your eyebrows go up just a little bit higher at the idea of people downloading and executing scripts as themselves?
And then look deeper and think about what the cookie is. Facebook and gmail offer you a cookie to send with future page requests as login credentials instead of having to enter a username/password or session identifier on every single page; that cookie is yoursand you are responsible for it and it shouldn't be sent out just whenever anyone wants to use it. And yet an img tag on some other website's page causes behavior that results in your cookie being sent to facebook? That's pretty much the essence of CSRF.
So we've got people running untrusted scripts, doing it as themselves, and CSRFs happening. And you're calling attention to HTTP status codes? Sheesh. That final tiny bit of the puzzle is insignificant.
Or just use NoScript w/ FF (Score:4, Informative)
Are you logged into Twitter ? (Please enable JavaScript)
Are you logged into Facebook? (Please enable JavaScript)
This is just a CSRF attack (Score:3, Informative)
The author of this article seems to have discovered the CSRF attack. Congratulations and welcome to the year 1990.
http://en.wikipedia.org/wiki/Cross-site_request_forgery [wikipedia.org]