Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross Site Cooking

Posted by Hemos on from the boning-up-on-the-bad-stuff dept.

Liudvikas Bukys writes "Michal Zalewski identifies a new class of attacks on users of web applications, dubbed Cross Site Cooking. Various browsers' implementations of restrictions on where cookies come from and where they're sent are weaker than you think. Web applications that depend on the browser enforcing much will offer many opportunities for mischief."

9 of 125 comments (clear)

  1. Web developers by mhanoh · · Score: 5, Insightful

    Any web developer worth their salt would be able to tell you nothing, and i mean nothing, sent or received over http should be regarded as secure.

    Of course cookies can be modified by a proxy. Of course sessions can be hijacked!

    1. Re:Web developers by dmeranda · · Score: 5, Interesting

      Unless of course you encrypt, or at least digitally sign all cookies you legitimately send.

      The fact that none of the cookie meta-data is ever sent to the server along with the cookie body is one of the biggest pains. Aside from the domain restriction that the article talks about, another big one is the expiration date. This is important if the server *wants* cookies to expire, such as if used for authentication.

      Thus a safe server will encode the cookie expiration date directly into the cookie value (as well as the cookie metadata), and then sign (or HMAC) the cookie value. And there's also the previously mentioned Ajax cookie stealing attacks to guard against, which usually means disabling the TRACE command or setting the secure cookie property.

    2. Re:Web developers by dasil003 · · Score: 5, Insightful

      Any web developer worth their salt would be able to tell you nothing, and i mean nothing, sent or received over http should be regarded as secure.
       
      Of course cookies can be modified by a proxy. Of course sessions can be hijacked!

      Right, but hijacking a session should require at least a man-in-the-middle attack. Allowing anyone to arbitrarily grab cookies from a visitor is a pretty big gaping hole. Obviously anything requiring serious security needs SSL and/or other cryptographic measures, but for the huge number of casual websites that only need basic authentication this really throws a wrench in the works, unless you want to ask the user for their password every single time they load a page.

    3. Re:Web developers by jacksonj04 · · Score: 5, Informative

      Alternatively, only drop a session tracking ID by cookie then maintain session expiry data on the server. With this it's possible to also do things like hostmask matching, so if the hostmask of the machine sending the session doesn't match one on the database, the password can be asked for again as verification.

      --
      How many people can read hex if only you and dead people can read hex?
  2. No site should trust client-side information. by bigtallmofo · · Score: 5, Insightful

    A basic rule of web design is that information submitted from forms and cookies stored on a client computer should at the very least be validated before processing.

    Otherwise, insecure browsers like TFA mentions are only one of your worries. What's to stop someone from modifying a cookie file with a hex editor? What's to stop someone from saving a local copy of your form and modifying it and submitting the modified form to your form processor?

    --
    I'm a big tall mofo.
  3. Never trust the input by MyNymWasTaken · · Score: 5, Informative

    Web applications that depend on the browser enforcing much will offer many opportunities for mischief.

    That is true regardless of what the exact nature of the issue is. Never trust user provided input.

    Expecting, not just a specific third-party program but, an entire class of programs to maintain your data integrity & overall security is sheer laziness or plain incomptence.

  4. I think you misunderstand by grahamsz · · Score: 4, Interesting
    Say you give some 64 byte randomly generated credential to the user as the cookie slashdot_cred. You store that in your database against their account, and then when they return that string you "know" that you've reached them. Typically that cookie is scoped to ".slashdot.org" so it can be read on it.slashdot.org and games.slashdot.org.

    Now, when the user visits evil.org it requests that a cookie called slashdot_cred be set for the site ".org." It has 2 dots in it, so it's set as a valid cookie and then next time you hit /. you'll hand over some alternate credential from evil.org.

    Opportunities for exploiting this seem very limited. The only one i can think of are store affiliate programs. I know that if you visit a link that i give you for shutterstock then they'll set a cookie with my id so that i'll get the referral credit if you sign up within 30 days.

    I'm not sure what goes into that cookie, but i might be able to make my own .com fake it and get credit for any signups that happen.

  5. The canonical DNS name problem by dmeranda · · Score: 5, Interesting

    As a DNS administrator, the trailing dot is something I was very aware of (although I didn't know about the cookie implementation errors). I've always wondered why you never saw URLs such as http://www.example.com./, instead of http://www.example.com/ ? The later (without the dot) is subject to local DNS spoofing.

    However, aside from the browser problems, it seems that web servers also mess up the trailing dot problem. Most servers won't recognize their own hostnames when the Host header has a trailing dot. Proxies are also clueless and confused.

    In fact, I was always surprised that the HTTP and URL standards (not to even mention the horrid X.509 certificate standards) seem so careless about the canonical domain name representation. There's no requirement, nor even a warning, about any use of the trailing dot in domain names, nor that any software (server, proxy, or agent) should do any sort of canonical name equivalence checking.

  6. How Google gets around this... by Sheepdot · · Score: 5, Interesting

    About two years ago I came up with a mechanism to base session cookies off of a series of md5 hashes along with the user-agent, screen resolution, and the Class B subnet mask and wrote up a document on how it could be done. Lo and behold I find that Google must have also independently figured out a way to do this as well. They implemented something like this into their gmail cookies, making XSS attacks damn near useless unless you're a good guesser or you know what you're doing when you do the cookie stealing and actually include javascript variables and record EVERYTHING you possibly can.