akutz: ** YOU COULDNT BE MORE WRONG **
SSL protects against many things, but it does *NOT* protect against XSRF. Which is -exactly- what you're opening yourself up to if you only rely on the cookie automatically sent by the browser in the form of the 'Cookie' header - which is the mechanism that tomcat et al generally use for session management. I'll repeat that, one more time: ** SSL IS NO DEFENSE TO XSRF; TOMCAT SESSION MANAGEMENT IS NOT XSRF PROOF. ** It is absolutely imperative that you send the SID along with every request. You aren't doing this to avoid 'people replacing the cookie'. Who replaces cookies? If someone has the power to replace your cookie, but only replace it, there isn't much to worry about, in general. Worst case leak is the paypal credit card harvester scheme (scroll down to the appendix of this post to read more about it), but even then this is a very complex attack: There's no simple way for any web page to set a cookie for another domain. It is easy, of course, if someone has direct access to the machine of the user, _but_, if someone has that access, then all security discussions are moot: He could also install a keylogger. Which you can't protect against at all. So no sense worrying about that case. To put it another way: Akutz - why do you think that reading the cookie from the SID is an 'obvious security flaw'? So, we're back to: Send the SID along with every request. Be aware that this is what happens anyway; how else does tomcat track state, you think? It reads the SID off of the cookie, that the browser sends in *every request*. Tomcat does this *every time* and uses the SID to look up your session (be it a db or other persistent store, or just from memory, that is an irrelevant detail for the security aspect of this discussion). Configuring it to 'share state in a persistent store', or any other setting, doesn't change this. At best, you can configure tomcat to not use cookies and instead use URL rewrites. This won't work in GWT, and is even less secure. I don't want to go into depth as to why that isn't secure, but just consider this: Digg, reddit, tipit, delicious, stumbleupon, and many other bookmarklets and browser bars offer ways to share websites. It has no idea about an SID in the URL; it'll instead happily share them. Resulting in other users of those sites logging in as you. Not to mention your SID showing up in referral logs when you follow links on the idiotic site that uses URL rewriting that lead to other websites. I've held this discussion every month or so on this forum and I'm sick and tired of it. Go do your research, or just search this newsgroup for previous posts. If you want to be pigheaded and do things your own way, you deserve the grief and the pain that's invariably coming to you when someone figures out you aren't XSRF proof. I've been fighting the good fight not so much for your sake, but for your users'. But even I have limits. Do me, and all your users, a favour, and send the session ID in the BODY of EVERY REQUEST, or you Fail At Security. Appendix: The paypal harvester scheme. Paypal's login page used to lack XSRF protection. If you had asked any security expert back then, he or she probably would have mentioned that it makes no sense to protect against XSRF -before- even logging in. After all, the pre-login page is the same for everyone. However, some enterprising soul 'hacked' paypal anyway: They created a link of the form: https://paypal.com/login?username=hackersname&password=hackerspass which was then opened in an invisible iframe. The poor user that browsed to the hacker's website (or a website hacked by the hacker) would unwittingly log into paypal as hackersname, invisibly. Nothing would happen though, and that by itself is not dangerous...... UNTIL this user visits paypal.com, intending to make a transaction, or, perhaps, to add a new credit card. *THIS* was what the hackers were after. Every so often someone would go to their paypal page, fail to notice that they weren't logged in as themselves, and add a credit card, THEIR credit card, to hackersname account instead of to their own. This didn't just allow the black hat to transfer money from your credit card to his own account, but it also allowed him to steal the full credit card info, as paypal listed all information back then, under the presumption that its the owner of the credit card that wants to know his own credit card's information. They had a simple bot running that checked every 5 minutes if a new CC had been added, and if so, grabbed the relevant information and removed the card from the paypal account. That issue has been fixed, but it is a rare example of a hack that involves XSRFing the login page itself. If you need to protect against it, send a random token to the user's page in cookie form along with the login form, and make sure it is parrotted back to you, in BOTH the body *AND* the header of the login. This means you need javascript, but, then, for GWT, you already need that anyway, so it doesn't matter. You don't even need to store this random token; as long as they match up and they have the right form (e.g. 32 characters long, vs. 'null' for the cookie and 'null' for the 'token' field of the form request, which would not be okay). On Dec 29, 11:08 pm, akutz <sak...@gmail.com> wrote: > Ultimately I think much of my concern will be moot because SSL will be > turned on at all times. However, I do love academic discussions. As > for #1, let's say we refresh the page or the user closes the browser > and comes back. Either of those events requires the application to > initializes its static variable for the SID FROM the cookie, yes? This > is an occasion where I do not see a good solution for improving upon > an obvious security flaw in favor of usability. > > As for #2, can Tomcat not be configured to store state (as long as it > is serializable) in a persistent store, such as a file system or > database? I am incredibly familiar with ASP.NET and web application > design in general, but am using GWT to create a cross-platform web- > app, so please pardon the newbish questions WRT Tomcat as an app-tier. > Doing some digging in my JSP book, it does appear that Tomcat can be > configured to use a shared state server for the purposes of clustering > web servers. In this case, doesn't #2 go back to "Let Tomcat handle > it"? > > Thank you again! --~--~---------~--~----~------------~-------~--~----~ 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 google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
