Slashdot Mirror
Abusing HTTP Status Codes To Expose Private Info
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.
Yes, that link is really neat!
HTTP 502 - Service temporarily overloaded
Half the text is cropped by an overhanging left-menu if I use my normal text size. Gah!
Ha. Possible. My alternative theory is that the new site is using our computers to make BitCoin. I have one core pegged at 100% utilization by Firefox when browsing the site.
Something bad is coming when people are suddenly anxious to tell the truth.
The new /. still sucks big time. Yeah. Mod me offtopic, why dontcha.
More likely redundant since everyone knows it already.
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.
It now takes 3-5 seconds to 'preview' a one line text post,
Wow, that's an improvement to before where it would take upwards of 10-20 seconds for the preview to finish.
Is here.
I doubt that halps against the technique presented in TFA, because it does not depend on Cookies or anything that is blocked in Incognito mode. Basically, they only rely to a HTTP request to the site to be checked, using JavaScript to determine the HTTP status. Thus, disabling JavaScript helps. The Firefox Addon "Request Policy" should, according to the autor of TFA, help, too.
It might not work as well as they think. I got this as I read down a bit:
Actually, I am browsing with Chrome, but have not opened GMail in this session at all, not once since the reboot. Maybe it is something Chrome is doing, since I get "No, you're not logged in" while using the incognito window.
If you are using your gmail account to download bookmarks, custom home page or whatever Chrome may be logging into gmail for, it may throw off the result.
However, in saying that, I noticed that it reported me logged into Facebook, which I am not, nor have I since my last reboot. I'm running Firefox 3.6.13.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
Everyone except those who should fix it, apparently.
Something bad is coming when people are suddenly anxious to tell the truth.
As the page is slashdotted, I just wanted to post how it is done here:
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.
You could write your own CSS or get an existing one
I don't see how his comment is flamebait. Increase your font size, you can easily replicate the bug he mentioned.
You can log in, however it gives you a blank cookie jar to start. You would have to log in to Gmail from within Incognito mode in order for this site to detect you.
You didn't say which browser you are using. The article states that the facebook/twitter detects don't work in IE or Opera.
It disables existing cookies.
If you go and log into Facebook within the Incognito session, yes, this trick will work. But it can't tell if you were logged in before that.
If corporations are people, aren't stockholders guilty of slavery?
Your login info could be stored in a cookie, in which case his image request will use the cookie info and automatically log you in.
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.
First of all. Lets check if you're logged into GMail right now (not including Google Apps)... (Please enable JavaScript).
:o
Are you logged into Twitter ? (Please enable JavaScript)
Are you logged into Facebook? (Please enable JavaScript)
Since when does being a Socialist mean 'someone who has a different opinion than me'?
It said Yes for me (after I allowed the site in NoScript in FireFox), even though I don't have gmail open. I did have iGoogle and Google Voice up, which use the same ID. I guess any page that uses the Google log in would show a Yes, after javascript is turned on. Yet another reason to use NoScript for me.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
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
I did a small amount of testing and it appears to me that this technique permits more leaks of user's behavior than stated directly in the article.
Lots of websites leave you "logged in" for a while, including /. This means that the user does not have to have an open page or tab, and may not perceive that he or she is actually "logged in." For example, amazon.com.
These sites produce a different page and results for certain actions depending on that status. It looks like Cardwell's method could detect this difference. Suppose you knew what shopping sites a user preferred? First, that provides likely demographic and gender information. Second, if in fact you were able to steal login credentials you would know immediately where you could use them. Third, you could use that information for social engineering in phising fraud. Fourth, you could promote your particular item for sale, on say, ebay or amazon.
Click that logout button, cowboy!
I will create a sig when innovation restarts in the U.S.
http://jeremiahgrossman.blogspot.com/2008/03/login-detection-whose-problem-is-it.html
Believe me, if I started murdering people, there would be none of you left.
I really can't believe this hasn't been solved for Firefox. The fix is really simple - if the content-type of the request is not javascript, then fire the onerror condition as well.
The other worrying thing is that you can perform actions that impersonate the user as long as they use GET requests. For example, I can log you out of Slashdot by putting the logout URL as the javascript source. I don't really see a way around that other than using HEAD requests for 3rd-party domains.