quentin: URLs aren't designed to be protected. At all. Cookies aren't exactly locked away in Fort Knox on your harddrive, but browsers at least have the good sense to understand that they shouldn't send arbitrary pieces in the cookiefile to arbitrary servers. Not so for URLs.
To wit: 1) 'aggregator' websites such as Digg, Reddit, stumbleupon, and even just del.ico.us or just mailing a link around because you want to show 'something cool' to a friend, always grab the entire URL and spill this out to the world at large. This is obviously really really bad. One 'fix' is to make these sessions time out fast, but this annoys users, and having your account accessible by anyone following a story on an aggregator for 'just half an hour' is still pretty bad. 2) Referral. When browsing to another domain, your browser will add a Referrer: header which contains the URL that the user came from. This is handy for analysis flow on your own site, and to figure out where people are coming from when visiting your site. If you run a website and you're using google analytics or some other traffic analyser, you may have noticed a '% of traffic from google' indicator. This thing works by checking how many incoming requests have a Referrer: (www\.)? google\.com.* - this referrer system does not discriminate and will happily toss over the ENTIRE URL, which would include your session. I could -easily- make a webserver that'll check if it looks like there's a session ID in a URL, then report it and the website via chat to me, so I can quickly see if I can log in as this person. 3) Bookmarks. web-based bookmarking was covered in #1, but even a local bookmark is relatively bad, because in general bookmarks are far easier to leak to another person than your cookiefile. sharing bookmarks is actively encouraged by many browsers. No user except a real geek would cut his URL down to eliminate the session ID from it (and even more pathetic, if this geek does do that, using the bookmark is near useless because he'll have to log in again. d'oh). 4) It's a giant sore thumb that both says: Geez, I'm ugly, and: OMG, I have absolutely zip squat idea about web security, so whatever info you give to me, consider it yelled from the rooftops. Boy, my webmaster is a thick headed clot. Most other security leaks aren't nearly as visible, which isn't much comfort, but it does count for a little that this one is so obvious. Just look at the address bar. NB: Yes, yes, the official java servlet spec, even the very latest version, officially declares that URL rewriting is amongst the strategies. Sun evidently considers background compatibility with dangerous code more important than security, which, to say it mildly, / annoys/ me just a tad. On Dec 2, 2:21 pm, quentin <[EMAIL PROTECTED]> wrote: > Reiner, > > Thanks for the reply. Call me naive/ignorant/stupid/whatever but what > are the security risks associated with using ";jsessionid"? The reason > i ask is because GWT cookie support in safari 4 appears completely > broken. (It's actually not GWT's fault. in safari 4, the js statement > "document.cookie = ...." doesn't seem to work). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
