Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Privacy

Abusing HTTP Status Codes To Expose Private Info 133

Posted by CmdrTaco from the i-see-what-you-did-there dept.
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.
This discussion has been archived. No new comments can be posted.

Abusing HTTP Status Codes To Expose Private Info More

Abusing HTTP Status Codes To Expose Private Info

Comments Filter:

  • HTTP 502 - Service temporarily overloaded (Score:3, Informative)

    by Anonymous Coward on Wednesday January 26, 2011 @10:14AM (#35008834)

    Yes, that link is really neat!
    HTTP 502 - Service temporarily overloaded

  • This is quite scary. Though, I always use the Incognito mode when browsing sites I don't trust as much as others (ahem).

    • Re:Incognito anyways (Score:5, Insightful)

      by PseudonymousBraveguy ( 1857734 ) on Wednesday January 26, 2011 @10:28AM (#35009014)

      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.

      • Re: (Score:1)

        by maxume ( 22995 )

        It depends on there being some authentication between your browser and the website being checked; for gmail, that's a cookie...

      • Re: (Score:2)

        by Nursie ( 632944 )

        Right, so blocking content from facebook.com (and fbcdn.com) except when you're on a facebook.com page, ought to work?

        Adblock Pro gives me the ability to disallow content when it's "third party" and I already make use of this feature. If the page wasn't /.ed I'd give it a try...

      • The technique does depend on cookies (if indirectly), since social networking sites (and indeed any site using sessions) depend on cookies to maintain their sessions. Incognito mode doesn't block cookies; it just makes sure they're deleted once you close the browser, so it won't provide any defence against the "attack".

        Also, it would be straightforward to adapt the technique to work in IE by using AJAX requests instead of script tags to query the URLs to be checked.

      • Yet another reason browsers need to sandbox sites from each other. No local file (cookie, flash cookie, DOM (HTML5) storage, browser cache, and of course URL history) should be accessible by any site other than the one that set it, in any way. If the HTTP requests were done in the same sandbox as the site performing them, they wouldn't have access to the other sites' cookies, and this problem wouldn't exist. This would also reduce the effectiveness of Facebook's and Google's tracking systems, but that's a g

  • The idea behind it... (Score:5, Informative)

    by ashidosan ( 1790808 ) on Wednesday January 26, 2011 @10:21AM (#35008926)

    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.

    • Re:The idea behind it... (Score:5, Interesting)

      by toetagger ( 642315 ) on Wednesday January 26, 2011 @10:28AM (#35009010)
      I don't know... What if I would do this in my slashdot signature, trying to load a picture only available for people on the RIAA Intranet. Then I could show a different signature to the RIAA than to everyone else. Copy/Paste for FBI, your HR/employer, or even your spouse.

      • Re:The idea behind it... (Score:4, Informative)

        by acooks ( 663747 ) on Wednesday January 26, 2011 @10:46AM (#35009216) Journal

        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: (Score:3, Informative)

        by natehoy ( 1608657 )

        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.

      • Re: (Score:2)

        by binkzz ( 779594 )

        I don't know... What if I would do this in my slashdot signature, trying to load a picture only available for people on the RIAA Intranet. Then I could show a different signature to the RIAA than to everyone else. Copy/Paste for FBI, your HR/employer, or even your spouse.

        Except that this is a different method altogether. It's always been possible to push different contents based on different IPs, but this is about being able to tell whether or not you're logged into certain websites or not.

      • What if I would do this in my slashdot signature

        I don't think /. allows javascript in signatures.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      If you know someone has an account on FB/Google/Hotmail/PayPal and are currently logged into it you could try using a phishing attack. PayPal in particular keep demanding your password if you are inactive for five minutes. History shows that users see password prompts simply as barriers to what they want to do and so will mindlessly type their secret into any vaguely official looking box.

      Law enforcement could use it to detect people with accounts on illegal sites too, e.g. Twitter or Facebook in countries w

      • How would this technique add any useful information to law enforcement's monitoring in countries with banned sites? Assuming I owned the HTTP stream (literally), I could discover pretty much whatever I want without resorting to this.

        Look what happened in Tunisia. Since they literally owned the HTTP stream, they just injected code to harvest personal information. XSS protection is useless if the basic stream is compromised.

        • Re: (Score:2)

          by AmiMoJo ( 196126 )

          Say the person logs in over a VPN or Tor. The cookie they get to be logged in is the same as an unencrypted connection so it could be used to determine if they were circumventing blocks or trying to hide their actions online.

      • Compute cycles are cheap when you're running a script on someone else's computer. Why not just try it anyway? If they're not logged in, it won't work. If they are, it will. Checking to see whether or not you think it will work is only useful if you care about the user you're about to rob.

        • Re: (Score:2)

          by sjames ( 1099 )

          Because even the people who mindlessly type in their password to anything that looks vaguely like their paypal account might wonder if they either don't have a paypal account or haven't gone to paypal. You don't want them reporting your site too soon.

    • There was a similar technique that determines if a site has been visited, using user history and CSS. creating a bunch of links and using the :visited CSS tag then use javascript to loop through the links to determine their visited status (ie, using width, or padding, or colour set by the CSS)

      The images thing seems to be along the same lines, as far as privacy issues go anyway.

    • And it doesn't work in all cases. It could not detect that I am logged into gmail.
  • I've never really used incognito in chrome, maybe I should start...

  • It might not work as well as they think. I got this as I read down a bit:

    First of all. Lets check if you're logged into GMail right now (not including Google Apps)... (Yes, you are logged in).

    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.

    • Re:Not quite (Score:4, Interesting)

      by ArcherB ( 796902 ) on Wednesday January 26, 2011 @10:31AM (#35009052) Journal

      It might not work as well as they think. I got this as I read down a bit:

      First of all. Lets check if you're logged into GMail right now (not including Google Apps)... (Yes, you are logged in).

      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.

      • Re:Not quite (Score:4, Insightful)

        by Pteraspidomorphi ( 1651293 ) on Wednesday January 26, 2011 @11:06AM (#35009480)

        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.

        • Re: (Score:2)

          by dzfoo ( 772245 )

          And the point is not necessarily to know if you're logged in, but that you are a Facebook user (because your browser acknowledges that it is or has logged in).

          Therefore, it succeeded.

                -dZ.

      • Re: (Score:2)

        by Anguirel ( 58085 )

        Firefox and Chrome both have options to "Save Your Session" when you log out. Most people tend to have these on, because they're remarkably convenient. However, it means Session-Only cookies are not deleted on browser close (or even a computer reboot). If you open Firefox and all your old tabs open right back up with where you were last time you were on, you probably have this enabled. So even if you haven't logged in to a given website in a couple weeks, you may still be "logged in" as the previous log

    • I received a similar message for Facebook further down the page. I have never, ever logged into Facebook on this machine.
    • 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.

    • Re: (Score:1)

      by Kakao ( 1626933 )
      And it told me I was not logged into Gmail while I was. Firefox 3.6.13.

  • The cached version (Score:4, Informative)

    by antido ( 1825442 ) on Wednesday January 26, 2011 @10:26AM (#35008992)
    Is here [googleusercontent.com].
  • Slashdotted. I guess everyone was curious!

  • How it works (Score:5, Informative)

    by mazesc ( 1922428 ) on Wednesday January 26, 2011 @10:34AM (#35009086)
    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.

  • A little bit of No Script goes a long way (Score:1)

    by Anonymous Coward

    The "Hack" seems to only work when scripts are enabled for the full base of a particular website. If I only enable static.ak.fbcn.net, I can still use facebook functionality but this "hack" can't tell that I'm logged in. The point of my story is if you're using Firefox with NoScript (and you have a vague idea what you're doing), you're still safe. I'm still wary of using Chrome.

  • It says I was logged into GMail (correct) and Facebook (incorrect).

    Not only do I not have a Facebook account to be logged in to, the computer I'm using has never directly gone to facebook.com. Other sites may have inlined facebook stuff, but I still don't have an account there.

    So what gives? No, no one else uses this computer. Yes, I am absolutely, 100% certain.

    • Comment removed based on user account deletion
      • You didn't say which browser you are using. The article states that the facebook/twitter detects don't work in IE or Opera.
        • Comment removed based on user account deletion

        • You didn't say which browser you are using. The article states that the facebook/twitter detects don't work in IE or Opera.

          They didn't work in Firefox for me. Had to disable AdBlock and the Facebook one still didn't work (but thats blocked at work). Twitter worked after disabling ad block though even though I've not been on it today.

      • Well, if you read how the trick works, then you will understand why "blocked by company fw" explains that... Error on loading the images indicates you are logged in.

    • It said I was not logged on to either GMail or Facebook although I was.
    • The one that i was logged into (GMail), stated I wasn't. It only got the ones correct that I wasn't logged into, perhaps because it doesn't work? I was using FF. I also call BS. -B
  • This doesn't work at all. I'm logged into Gmail and Facebook, neither of which it detected.

  • Ho hum (Score:2, Informative)

    by davidbrit2 ( 775091 )
    Another day, another guy thinking CSRF is something new.

  • I was logged into Slashdot and that bloody web page said I was logged into facebook. I would NEVER use facebook. Damn liar....mumble mumble

    • I suspect this method has a "bug" or its not working as expected in Chrome:
      1) I am logged into Google apps, but it says I am not.
      2) I do not have a twitter account, but it says I am logged in (and its blocked by Websense).

      Something odd is afoot.

      • Re: (Score:2)

        by Zenaku ( 821866 )

        He states that the Gmail version doesn't detect if you are logged into Google apps.

        I suspect that his technique shows you as being logged into twitter BECAUSE it is blocked by Websense. His method for detecting a twitter login relies on attempting to access a twitter URL and looking at the HTTP status code that comes back. In your case Websense is not allowing the connection to twitter, but it is returning a valid HTML page with an OK status -- the page that says you've tried to access a site that is bloc

  • I wouldn't call this status code abuse (Score:2, Informative)

    by Anonymous Coward

    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 ey

    • Re: (Score:2)

      by Lennie ( 16154 )

      The real solution is to set a cookie with a path on the site where people are logged in and not have any images in that path on the webserver.

      • Re: (Score:2)

        by Lennie ( 16154 )

        Or use a different domain ofcourse.

      • Re: (Score:2)

        by Lennie ( 16154 )

        I re-read part of the article, seems not all browsers check if it is valid javascript if a script-tag is used. I consider that a browser bug.

  • Or just use NoScript w/ FF (Score:4, Informative)

    by 228e2 ( 934443 ) on Wednesday January 26, 2011 @11:26AM (#35009692)
    First of all. Lets check if you're logged into GMail right now (not including Google Apps)... (Please enable JavaScript).
    Are you logged into Twitter ? (Please enable JavaScript)
    Are you logged into Facebook? (Please enable JavaScript)

    :o

  • This is just a CSRF attack (Score:3, Informative)

    by brunes69 ( 86786 ) <slashdot@nOSpam.keirstead.org> on Wednesday January 26, 2011 @11:33AM (#35009760)

    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]

    • That's exactly what he's done. I'm surprised more people aren't yawning over this. I remember when this was demonstrated only showing your gmail contacts instead of just whether you're logged in or not.

      The only novel thing he appears to have done is trying to load a static resource that requires you to be logged in. I haven't seen it done this way before, but it's a small refinement on an existing attack, not a novel attack.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Pray tell, how would one have executed a CSRF attack in 1990?

  • Only he thinks I'm logged into Facebook. But I don't have a Facebook account, so I can't be. And this is my work computer which gets locked when I leave my desk so no one else has logged in (plus I have an office door that I lock behind me).

    *tin foil hat time*
    I even have *facebook.com and *fbcdn* blocked in AdBlockPlus though since I don't really want Facebook building a user-profile about me with all those nefarious "like" buttons it got chumps to place on none-facebook sites. They dont' need to know wh

    • There is perhaps a simple explanation for it, as the script only checks the return code and not the contents, an error page created by a corporate firewall (or something similar which blocks facebook with some explaining page) could also return 200 instead of an error and it would show you as logged in.

  • I read the article and tested if the code works -- and it does. However, the article is somewhat misleading -- or at least I found that it was not as clear as it should have been with "logged in."

    For example, I logged into my gmail account, and close the tab without logging out. The code from the article shows that I am still logged in -- true from a technical standpoint, but I closed out the gmail tab already. Likewise with facebook. However, all the code can really do is test whether or not the current

  • Worse than you think (Score:3)

    by xkr ( 786629 ) on Wednesday January 26, 2011 @12:13PM (#35010278)

    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!

    • This is a standard CSRF attack that leaks less data than most. The potential for abuse is far smaller than the potential for abuse with any of the attacks that leak your browser history.
  • When I learned about cross site scripting I insalled Noscript right away.

  • Somebody submit a bug report (Score:3)

    by omnichad ( 1198475 ) on Wednesday January 26, 2011 @03:25PM (#35012822) Homepage

    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.

    • Re: (Score:2)

      by mgiuca ( 1040724 )

      That wouldn't work for the Google example -- the content-type of the <img> is an image type. Similarly, if the site was actually serving JavaScript only to logged-in users, you could request one of those resources in the <script> tag.

      • I believe you didn't read it clearly.

        It's a script tag pointing to an image at Google INSTEAD of a script file:
        <script type="text/javascript" onerror="logged_in()" onload="logged_in()" src="http://someimageatgoogle"></script>

        It was returning successful when the content loaded, regardless of the actual content-type returned. Even though, instead of text/javascript, it actually returns image/gif and binary data, the event handlers return based on the HTTP status code rather than the success of ac

        • Sorry - one of those logged_in() should have read not_logged_in()

        • Re: (Score:2)

          by mgiuca ( 1040724 )

          No -- the Facebook and Twitter ones work like that. The Gmail exploit, in TFA, is the following code:

          <img style="display:none;"
                    onload="logged_in_to_gmail()"
                    onerror="not_logged_in_to_gmail()"
                    src="https://mail.google.com/mail/photos/static/ <snip to avoid Slashdot filter >" />

          So it's an image loading an image, just from a different domain.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close