Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Programming The Internet IT Technology

Cross Site Cooking 125

Posted by Hemos 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."
This discussion has been archived. No new comments can be posted.

Cross Site Cooking More

Cross Site Cooking

Comments Filter:

  • Web developers (Score:5, Insightful)

    by mhanoh ( 303815 ) * on Monday January 30, 2006 @07:11PM (#14602733)
    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!

    • Re:Web developers (Score:5, Interesting)

      by dmeranda ( 120061 ) on Monday January 30, 2006 @07:21PM (#14602809) Homepage
      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.

      • Re:Web developers (Score:5, Informative)

        by jacksonj04 ( 800021 ) <nick@nickjackson.me> on Monday January 30, 2006 @07:42PM (#14602929) Homepage
        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.

        • "Alternatively, only drop a session tracking ID by cookie then maintain session expiry data on the server."

          Indeed. I would have thought it was common sense to pass no data at all in a cookie, except a session token. I think every app I've written in the last 6 years uses cookies for session tokens only. It doesn't completely protect you from man-in-the-middle attacks hijacking a session and altering data on the server, but it does help reduce the amount of information that can be stolen. And as a general

          • I also use cookies for display preferences which might reasonable change from browser-to-browser or host-to-host for the same user.

            Nothing critical, though; worst case scenario, the attacker makes the screen look a little funny. Whoopie.

            • Nothing critical, though; worst case scenario, the attacker makes the screen look a little funny. Whoopie.

              And when the attacker has trained the user(s) to ignore the unexpected screen features or password prompts, then it is time to launch a "misspellled domain name" or other such attack.

        • While this is a possible alternative, excessive database calls every time one loads a page for multiple users many times a day could bring a server to its knees. This of course only applies to MySQL or Oracle and other third party database applications that take up large ammounts of CPU. It might be preferable to place this information in a flat database text file in a directory inacessible via the web for example: /inacessiblefolderwithsomesalttomakesureitssafe12 3 4554321/cookies.txt instead of /public_htm
      • > This is important if the server *wants* cookies to expire, such as if used for authentication.

        If you want the cookie to expire, then put an expiration date in your cookies table. You can also send the expiration date to the browser, but be aware that some browsers allow the user to arbitrarily modify the expiration date at the browser end. You *could* encode the expiration date into the cookie, but then things start getting complicated and you end up with needlessly complex cryptographic schemes. Ba

    • Re:Web developers (Score:5, Insightful)

      by dasil003 ( 907363 ) on Monday January 30, 2006 @07:33PM (#14602877) Homepage
      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.
      • "Right, but hijacking a session should require at least a man-in-the-middle attack."

        I'm starting with the man-in-the-middle,
        (Man-in-the-middle -Oh yeah!)
        I'm asking him to change his ways
        (Better change!)
        No message could have been any clearer
        (If you wanna make the world a better place)
        (Take a look at yourself and then make the change)
        (You gotta get it right, while you got the time)
        ('Cause when you close your heart)
        You can't close your... your mind!
        (Then you close your... mind!)
    • 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.

      Oh, the old "the only secure machine is a machine that is switched off, thus security is a lost battle anyways, so we should not waste any precious time implementing security" canard.

      Yes, statistically, all non-trivial protocols will indeed have (unknown) security holes, but that should not be an excuse to leave known security holes unpatched when they come to

  • Cross Site Cooking? (Score:1, Funny)

    by Anonymous Coward
    Don't you bake cookies?
    • Reminder:
      This is slashdot.

      95% of the readership believes there are two kinds of cookies... those that magically appear in mom's cupboard (or a speacial jar) and those that are generated by a webserver. How the former ones come into existance is of little consequence.

  • No site should trust client-side information. (Score:5, Insightful)

    by bigtallmofo ( 695287 ) on Monday January 30, 2006 @07:14PM (#14602753)
    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 think you misunderstand (Score:5, Interesting)

      by grahamsz ( 150076 ) on Monday January 30, 2006 @07:22PM (#14602811) Homepage Journal
      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 [shutterstock.com] 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.

      • Re:I think you misunderstand (Score:1, Insightful)

        by Anonymous Coward
        I'm wondering if you're just spam on a cookie. Slick self-promotion, there. Not sure if I should complain, or admire the way you did it.
      • Opportunities for exploiting this seem very limited.

        That depends on how the target web site manages its authentication. Some web sites establish a session before the user supplies his credentials. This session is marked "anonymous" in the site's db, until the user is authenticated. On authentication, the (random) cookie is not updated, but only the site's database associating that cookie with a user.

        An attacker could exploit this by foisting a cookie for the target site on the user. Initially, the cookie

      • You missed my point. It was that if your site relies on a secure browser (as the article stated) or data that is stored client side (cookies), you have many worries, not just the one outlined in the article.
        • How else could a site work?

          You need to emulate stateful behavior, so you have to have some way to recognize that a client has returned. Giving a cookie to the client is the only way i can think of to recongize the returning client.

          Typically you make sure that you either give the client some random data that you've associated with them, or perhaps a cryptographically signed token. The idea being that that if the client modifies it then it'll be worthless.

          However nothing stops the client swapping credentials
    • Or at least I hope it is. Devs definitely need to set up server-side security for this reason. You can't get them all, especially if they REALLY want in, but you can at least do your best on the client side.

      Of course, everyone knows that if you just comment it out, it disappears. :o
    • What's to stop someone from modifying a cookie file with a hex editor?

      Changing cookies is even easier than that in the Mozilla family of browsers, with the Add'n'edit Cookies extension [mozdev.org]. You're right that, in general, cookies should be treated like POST or GET data, which can be full of crap you, as web designer, don't want. Just like POST and GET data, it should be thoroughly cleaned if it's to be used within an SQL query or to look up a file in the filesystem. The extension, though, is a great way to deb

    • This is why I so appreciate Perl's "taint checking" mode. In this mode, *all* data obtained from external sources -- http payload, env, read from a file -- is considered tainted until it's been the object of a regex pattern match, which turns off the taint bit. Tainted data cannot be used in any action that will have external effects -- writing to output streams, calling system execs, etc.

      It's not perfect, of course, but it's alerted me to potential security problems dozens of times.
      • This is why I so appreciate Perl's "taint checking" mode. In this mode, *all* data obtained from external sources ... is considered tainted

        Except that this only allows you to protect against lack of datavalidation/escaping bugs (SQL injection, etc.), not against this attack.

        The cookie planted by the attacker looks legit at first glance (the attacker may very well have gotten it from your site in the first place, before foisting it on an unsuspecting victim). The problem lies not in the cookie's contents,

  • Never trust the input (Score:5, Informative)

    by MyNymWasTaken ( 879908 ) on Monday January 30, 2006 @07:14PM (#14602756)
    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.

  • cookies insecure (Score:1, Informative)

    by amazon10x ( 737466 )
    Wasn't this demonstrated when some guy managed to steal a bunch of passwords stored in cookies. It would grab the cookie when they visited his site and he would look through them and access accounts accordingly. I think this happened on a social netowrking site (myspace?)
    • I found a link [washingtonpost.com] about this with LiveJournal. Bantown members said they created hundreds of dummy member accounts featuring Web links that used the Javascript flaws to steal "cookies" (small text files on a Web-browsing computer that can be used to identify the user) from people who clicked on the links. Armed with those cookies, the hackers were then able to either log in as the victim, or arbitrarily post or delete entries on the victim's personal page.
    • after all, using cookies is MUCH better than storing the sID in the query string :-S

      Of course, i'm all for IP validation.
      • The problem with IP validation is the people on dial-up get different IPs all the time (some DSL/Cable users get different ones too). Therefore, the IP would not validate and they would have to login everytime they disconnect.
        • and whats the problem with forcing the user to login to a website again after the disconnect from the internet and get a new IP?

          Seems to me that if the user wanted to stay logged in and if the site has the functionality to remember user names/passwords by saving the information in the browser then they could easily login again...

          Personally I say - validate IP's, user agent, login name, session ID and time of day ( I kill idle users )

          I've also been throwing around a more secure authentication scheme: FIFO Ba
      • As handy as IP validation is for the most part, it does make your site useless to any one working through a constantly changing proxy. A small audience, but still considerable.
        • AOL being a prime example here (unless they have changed in the last few years).

          Also, persons infected with certain kinds of spyware. Which suits me just fine.
          • It's still very much a problem. It wouldn't even be so bad if they set the X-FORWARDED-FOR header correctly, but they don't. I've contacted them about it, in my role as security architect for a very large company, but the response was basically "Yes, we know about it. No, we aren't going to fix it."

            Unfortunately I don't have the freedom to detect AOL IP blocks and return a page saying "Hey, due to our concerns for your security, and AOLs lack of concern for your security, we can't service you until AO
  • Of the three points, the middle (trailing dots on domain names) is the only one I hadn't considered already, as I thought browsers were smart enough to avoid it. Is there a list of browsers actually affected by it somewhere?

    • The canonical DNS name problem (Score:5, Interesting)

      by dmeranda ( 120061 ) on Monday January 30, 2006 @07:29PM (#14602850) Homepage
      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./ [www.example.com], instead of http://www.example.com/ [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.

    • Re:The second one suprises me (Score:4, Informative)

      by Ark42 ( 522144 ) <slashdotNO@SPAMmorpheussoftware.net> on Monday January 30, 2006 @07:49PM (#14602965) Homepage
      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.

  • Work arounds.... (Score:2, Informative)

    by IAAP ( 937607 )
    The Firefox extension: "SpoofStick" can help - I think.

    FTFA: One can set a cookie for ".com.", then bounce the visitor to http://www.victim.com./ [www.victim.com] .

    I'm thinking plugins like the one I mentioned would help a user from getting screwed like this. I'd be curious as to other methods.

  • Opera (Score:3, Interesting)

    by Joebert ( 946227 ) on Monday January 30, 2006 @07:23PM (#14602815) Homepage
    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 ?...
    • 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)
      But if you obviously refuse them, you could as well disable the warning! :)

    • Re:Opera (Score:1, Informative)

      by Anonymous Coward
      The Incorrect Paths thing is handy, but I refer you here:

      http://nontroppo.org/wiki/CookieSettings [nontroppo.org]

      I would never have worked out Opera's cookie handling without this. Now, it works nicely.

      Clear out all your old cookies. Set Opera to accept anything. Go to all the sites you trust and log in and out. Then set your cookies to Normal: Treat as specified in Server Manager; Third-Party: Accept All.

      Do a quick review[1] to be sure there's nothing unwanted left in the list. Opera stops bothering you about crap co

    • Re:Opera (Score:3, Interesting)

      by CTho9305 ( 264265 )
      I love SeaMonkey.

      I've got SeaMonkey set to allow persistent cookies from sites on my whitelist, and session cookies only for other sites.

  • Nasty (Score:3, Insightful)

    by dasil003 ( 907363 ) on Monday January 30, 2006 @07:23PM (#14602822) Homepage
    Well I can't say this was unexpected, nevertheless, it's pretty nasty considering that cookie trust is the standard way of keeping someone logged in. I suppose you could implement IP checking as an additional security measure, forcing wireless users to constantly re-login, but it would provide significant security improvements.

    What it really goes to show is that web applications should always require a password to be entered for any 'sensitive' transactions. The definition of 'sensitive' is left as an exercise to the web developer.

    • Re:Nasty (Score:3, Insightful)

      by coolgeek ( 140561 )
      IP Checking won't work, unless you want all your AOL-based visitors to keep getting logged out. I think some Cable users too. Basically anyone that has a proxy-cluster between their browser and your site will come from several different IPs as they surf your site.

      • Re:Nasty (Score:3, Funny)

        by dasil003 ( 907363 )
        ...unless you want all your AOL-based visitors to keep getting logged out.

        Uhhhhmmmm...

        Nah, it's too easy.

        Seriously, good point, it just underscores the problem.
      • If only people consistently set the X-FORWARDED-FOR header when proxying requests. AOL doesn't. A fair number of folks do, but AOL is such a large customer base, that business-wise we can't exclude them. I'd love to get the message out to AOL users that despite AOLs advertisements about being all about your security, their refusal to implement a simple feature in their proxies, reduces the security of just about every e-commerce site online.

        Anyone want to run a 5 minute special on CNN? *grin*
        • Of course, you could ONLY accept the X-FORWARDED-FOR header for *known* 'safe' 'official' proxies, that are known to:

          a) Delete the header if it already exists from the client.
          b) Set the correct value for this header.

          Just relying on that header if it's there is the worst possible thing you could do, as any client can add that header to say whatever they like.
          • Sure, but in the case of AOL, their proxies are a nice published list, so that's very doable. And frankly it's better than not being able to do any IP validation. It isn't perfect, but it raises the bar from simple link or cookie thieves.
            • Yeah, I'm not disagreeing with you.. Just clarifying in case anyone read your post and said "ooh, that's a good idea, I'll start parsing X-FORWARDED-FOR" if it exists.

              You'd also have to test before you rely on this feature of a proxy that the proxies "do the right thing" if the user tries to spoof the X-FORWARDED-FOR client-side, which would presumably mean getting an account via that ISP to test, but I realise you know that already..
      • Laptops. There are many of us who find ourselves working out of hotels, airports, wherever. Having to log in again to multiple sites all the damn time would suck.

        Because you know what? The only places where I stay "logged in" are the ones that I don't care about. My bank makes me log in every time I use it - fair enough. But slashdot? Who gives a rat's arse? What's worse, the main people who would implement this would be the very people for whom security should be the least concern, like the vendor m

    • Good idea! (Score:3, Interesting)

      by Spy der Mann ( 805235 )
      How about this - some sites could implement IP validation, _IF_ you allow them too.

      If I'm a paranoid, tinfoil-hat slashdot type, i could check on the "perform IP validation for a greater security" option.

    • Not THAT nasty (Score:3, Insightful)

      by sterno ( 16320 )
      If I'm reading this correctly, it's not that bad for most websites these days. There are two exploits that I see are possible from this.

      1) Pushing a hacked cookie to the client that then is transmitted to a legitimate site
      2) Stealing data contained in a cookie

      In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as

      • Re:Not THAT nasty (Score:3, Insightful)

        by Metasquares ( 555685 )
        There's the possibility of setting up some sort of DDoS attack by modifying cookies sent to a server in order to construct huge queries, but that means there has to be an SQL injection vulnerability on the server as well. Of course, you should validate and escape anything you put into a query from a user, whether it's a POST variable or a cookie.
        • This is partially avoided by the size limits that are placed on a cookie. Frankly though you've got bigger issues if you're that trusting of a cookie's contents :)
          • It isn't that the cookie is huge; the problem is that if you stick some JOINs, or perhaps even an OR 1=1, into a query, it can really drag down the DBMS if you have enough rows. MySQL's documentation [mysql.com] has some information on how that can happen.

            I agree, though; if you're not validating what your cookies are sending you in some way, you do likely have larger problems.

        • you could just make a batch file which pings the server a lot, modifying cookies seems a little overkill for DDoSing. of course DDoSing is moronic like most malicious hacking so w/e i'm just saying :P dont think i defend either way or anything.
        • but that means there has to be an SQL injection vulnerability on the server as well.

          For these kinds of things, there's a far easier trick than cookies: use the injection URL (usually, a form submitted using GET action) as an image URL and put it on your site (or better, on another site with an SQL injection vulnerability...). Result: a self-refreshing SQL injection attack...

          The sysadmin of the main target can remove the lovely goat man from his site as often as he wants, he keeps coming back! And each ti

      • Re:Not THAT nasty (Score:4, Insightful)

        by iabervon ( 1971 ) on Monday January 30, 2006 @09:25PM (#14603481) Homepage Journal
        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).
        • Interesting twist on it. Only problem is under both scenarios, I'd be readily able to track you down :)
        • Maybe I give you a session where your shipping address is my house.

          How would that work? You seem to assume that sites store information in a cookie. That's not how most of them do it. They generate a random md5, set that as a cookie, and save a copy in their database. A session key maps to an entire account, not to a piece of an account.
        • 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).

          Most reliable sites also do an IP address check (in addition to just using the cookie-based session) to prevent against session hijacking [google.ca].

      • In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as me... great... so you can log take all my money? I mean there may be some strange setup that this can be used to exploit but I should think it's a rarity.

        You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the se

  • How Google gets around this... (Score:5, Interesting)

    by Sheepdot ( 211478 ) on Monday January 30, 2006 @07:46PM (#14602949) Journal
    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.

    • Re:How Google gets around this... (Score:1, Insightful)

      by Anonymous Coward

      You are heading away from security, not towards it. A good session cookie is one that is unpredictable. That means random, not based on information the attacker could conceivably get access to like screen resolution.

      Seriously, what's wrong with generating session cookies randomly that you felt the need to "fix"?

      • A good session cookie is one that is unpredictable. That means random, not based on information the attacker could conceivably get access to like screen resolution.

        If you use a keyed hash, you can get the benefit of both cookies you can check for validity and cookies that an attacker cannot guess.

      • Seriously, what's wrong with generating session cookies randomly that you felt the need to "fix"?

        Cross-site cooking, maybe? ;-)

        If you encode some client identifying info into the cookie, in addition to a random seed, you protect against attackers grabbing a cookie from your site, then foisting that cookie on an unsuspecting victim, and finally coming back to reap the rewards...

        The client info would prevent step 2 (because the server will notice that it never handed out that cookie to the victim, and jus

    • All of those things are terribly non-unique. In fact, most people I know run either Firefox or IE with a resolution of 1024x768.

      Subnet mask is obviously non-unique.

      That's not much in the way of variety there.

      I guess you add some resistance to XSS, but you don't stop it entirely using that.

      While you're at it, though, why didn't you include IP address?
      That's a lot more unique than all of the other things you mentioned. Obviously it'll change in the case of dynamic stuff, but probably not as fast as session

  • Opera (Score:2, Informative)

    by Rits ( 453723 )
    Opera is the one browser that was apparently not researched, as the issues do not show there (#2) or are less severe (in case of issue #1). People sometimes complain that Opera throws a warning for (or refuses) a cookie that the other browsers happily accept. This is no error, just Opera better at following the specs like RFC 2965...
    • I have FF set to ask me about all cookies. It is not that hard to accept/deny and it is interesting to see the common tracker cookies across many sites.

      qz

    • Re:Opera (Score:3, Funny)

      by mrdaveb ( 239909 )
      Kryten: RFC Directive 2965 'No officer above the rank of mess sergeant is permitted to go into combat with pierced nipples'. Sorry sir, I fail to see the relevance

  • Formkeys (Score:2, Informative)

    by Bemmu ( 42122 )
    I wrote about this [bemmu.com] a while back, warning community sites about it. That was before the MySpace chaos. Formkeys help as a basic precaution, although they may also be read and passed on by ajax techniques.

  • Microsoft have been doing this for years (Score:3, Informative)

    by Anonymous Coward on Monday January 30, 2006 @07:59PM (#14603033)

    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) [pc-help.org]
    news report here [com.com]

    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

  • The exploit "Problem #3" won't work if the "victim" is already on virtual host. In this case, the web server would not recognize that it is hosting a site for evil.example.com and show the default site (if one is configured), not the desired site. For those who did not pay a premium to get a dedicated IP web hosting, this is a non-issue.

    In general, I think cookies should only be allowed if the domain suffix of the cookie matches the host name---so www.example.com can set cookies for www.example.com and *.ww

  • This can be used in DoS attacks... (Score:4, Interesting)

    by Alascom ( 95042 ) on Monday January 30, 2006 @08:25PM (#14603176)
    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 [terrorist.net] )
    • Not to be an over-correcting troll, but the cookie limit is 4KB, or up to 20 name-value pairs per domain. Seems like the best you could hope for would be corrupting all cookies under .org, and adding another second or two to the initial request.
      -imgunby
      • Maybe in theory, but in practice I can tell you that isn't true. I've known somebody who was experimenting with storing certain non-sensitive user history data in cookies rather than the database, and eventually started getting 500 Internal Server Error from Apache because the cookie was longer than the maximum allowed request header size (for 1.3.x, I believe it is 8k by default, but can be increased at compile time)
        • That I don't doubt, but IE is just strange when it comes to cookies in general, and that assumes that everything between client and server correctly handles and passes that much header data, and I can tell you that AOL's proxies are pretty strict when it comes to that sort of stuff.
    • there is a very easy way to undo that, when slashdot recieves one of those cookies the user sending it is directed to a page instructing them to delete all cookies from slashdot.org and re-login.
    • oh, so your "wicked" attack requires that you first get slashdotted? if you're already slashdotted and want to launch an attack, why not just redirect/send all visitors to an alternate page with as many hidden frames as you like, which all load the slashdot main page? that would increase the size of the "attack" many, many times over what you've described.
    • Comment removed based on user account deletion

  • Don't Use Cookies: Most Sites Don't. (Score:1, Informative)

    by Anonymous Coward
    Rewrite URLs with encrypted data as required instead.

    Only 22% of servers use cookies [securityspace.com]. The best sites work fine without them.

  • And was interested.

    My question to the powers that be here who control cookies is why do so many site expire in 2016 or 2038?

    qz

    • Re:I read TFA... (Score:1, Informative)

      by Anonymous Coward
      Because that's the latest they can.
    • A conjecture about this would be that 2038 is the ending of UNIX time. The maximum numer of seconds a signed integer can hold is 2 ** 31 - 1. So all as far as all Linux boxen are concerned the world ends on:

      > perl -le 'print scalar localtime 2 ** 31 -1;'
      Mon Jan 18 21:14:07 2038

      Monday January the 18th, 2038. This is probably why they always are set to expire in 2038. Don't know about 2016.

      And this explanation could be bull anyway.
    • 2016 is exactly 10 years in the future.
  • For anyone who might be turned on by Michal's geekyness - you should be aware that he's not a girl, unlike what his name might imply.
  • SAML implementations (shibboleth, lib aliance etc) for distributed authentication usually include WAYF (where are you from) servers that direct a user to their home site for authentication purposes.

    It's often the case that a WAYF implementation will utilise a cookie in order to "remember" the user's home site, permitting either the selection of an appropriate default or the automatic redirection to the user's local SSO origin.

    The replacement of that cookie would mean the user doesn't wind up going to their

  • Nothing new (Score:3, Interesting)

    by ajs ( 35943 ) <ajs.ajs@com> on Tuesday January 31, 2006 @09:29AM (#14606162) Homepage Journal
    I'm under NDA, so pardon me while I dance a little... a certain large company with whom I have done business in the past, and which maintains a large stable of popular sites, once sent us their cookie documentation. As a partner site, we were required to play ball with this document, and I can only describe it as vile. It was a manual akin to the anarchist's cookbook, but for subverting the trust of our users. The information coming out about cookies is not "theoretical", it is practical and widely used by the largest sites.

    If you don't believe me, turn on manual cookie accepting, and start visiting the largest sites on the net. Accept all cookies for just the session and see what you get. I assure you that you will see these games played, not by disreputable hackers, but by the companies that many thought they could trust. You will see your personal information (to the extent that company A has it), handed off to company B in ways that HTTP was not supposed to allow for. You will see a great many interesting things.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close