Slashdot Mirror

← Back to Stories (view on slashdot.org)

Abusing HTTP Status Codes To Expose Private Info

Posted by CmdrTaco on 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.

14 of 133 comments (clear)

  1. HTTP 502 - Service temporarily overloaded by Anonymous Coward · · Score: 3, Informative

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

    1. Re:HTTP 502 - Service temporarily overloaded by prxp · · Score: 3, 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

    2. Re:HTTP 502 - Service temporarily overloaded by Steve+Max · · Score: 3, Informative

      I believe you're supposed to abuse the HTTP error code somehow to get the content.

      Corel Cache also works.

  2. Re:And let's not forget... by pbhj · · Score: 2, Informative

    Half the text is cropped by an overhanging left-menu if I use my normal text size. Gah!

  3. The idea behind it... by ashidosan · · 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.

    1. Re:The idea behind it... by acooks · · 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. "

    2. Re:The idea behind it... by natehoy · · 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.

      --
      "This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
  4. The cached version by antido · · Score: 4, Informative

    Is here.

  5. How it works by mazesc · · Score: 5, Informative

    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.

  6. Re:And let's not forget... by roka · · Score: 3, Informative

    You could write your own CSS or get an existing one

  7. Ho hum by davidbrit2 · · Score: 1, Informative

    Another day, another guy thinking CSRF is something new.

  8. I wouldn't call this status code abuse by Anonymous Coward · · 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.

  9. Or just use NoScript w/ FF by 228e2 · · Score: 3, Informative

    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

    --
    Since when does being a Socialist mean 'someone who has a different opinion than me'?
  10. This is just a CSRF attack by brunes69 · · 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