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."

14 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. Opera by Joebert · · Score: 3, Interesting

    I love Opera.
    I've got Opera set to warn me about cookies with "incorrect paths", I've been getting alot of warnings about cookies lately. (which I obviously refuse when they come up)

    Should have known somthing like this was going on with all the questions about cookies & paths on Webmaster Forums awhile ago ya think ?...

    --
    Wanna fight ? Bend over, stick your head up your ass, and fight for air.
  6. 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.

  7. 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.

  8. Re:The second one suprises me by Ark42 · · Score: 3, Informative

    Yeah, that one surprised me as well, and he made it seem like modern browsers where still affected, but a simple PHP script:
    <?
        SetCookie("Test","Value",0,"/",".com.");
        print_r($_COOKIE);
    ?>

    Did not work in Firefox or IE6 for me, so those browsers at least, seem safe from this.

    --
    Morphing Software
  9. Microsoft have been doing this for years by Anonymous Coward · · Score: 3, Informative


    with MSN network, we (large corp) banned all of their MSN domains as this is a security risk and as its intentionally deceptive on their part we had to classify it as malicious due to the intent

    here (with analysis)
    news report here

    of course MS still use it and the surfers still have no idea its occuring, though if you block their servers you soon find out how many times they try.

    never mind trusting the user, its the server and the company that does it that people cant trust

  10. This can be used in DoS attacks... by Alascom · · Score: 3, Interesting

    I believe I have found a really wicked attack that could utilize this method to implement a serious DDoS effect. Lets consider issue #1, where I can create cookies in .org.

    When a user visits my site, I set 20 cookies for slashdot.org. that are 4KB in size each (maximum number for a domain, and maximum allowed size per cookie). I also set the expiration for some time far into the future. I only have to send this data to each visitor 1 time.

    As a result, everytime the user goes to slashdot, he transmits 20*4KB (80KB) of data at slashdot. Not a big deal right? But what if my site is slashdot'd, and a million faithful readers visit my evil website and get this bogus cookie data. Now slashdot will be flooded with 80KB from 1,000,000 users every single time they click on any slashdot page (potentially for years). Yikes! Slashdot becomes victim of covert and malicious /. effect having serious financial impact on Slashdots bandwidth costs.

    This is a potentially serious amplification attack vector that would be really hard to clean-up.

    --
    This attack ©The Terrorist Network ( www.terrorist.net )

  11. Re:Not THAT nasty by iabervon · · Score: 3, Insightful

    Maybe I give you a session where your shipping address is my house. You buy some stuff from the site, don't pay much attention, and have it shipped to me. Or I give tons of people shopping carts containing something I sell through Amazon. Some of the people don't pay attention and accidentally include my item in their next purchase. Or I create a session with a site but don't log in, and I give it to them. They use it, find they aren't logged in, log in, and I'm also logged in as them (since I'm using the same session).