Replies inline... On Nov 29, 2:08 pm, gregor <[EMAIL PROTECTED]> wrote: > > a) Don't send sessionID as cookies - deliberately configure app server > to stop it using cookies for tracking sessionIDs
This does mean that sessions don't survive the user reloading the page or closing his browser. This is generally speaking not acceptable to most GWT developers. My point was: They are in the cookie -anyway-, so worrying about the session ID hitting the wire, while fruitful and of some concern, is outside of the norm. 99% of all websites take this risk. The Sheep Routine (be like everybody else) is *NOT* in general a wise path to take in regards to security, but unless there are a non- trivial amount of non-insane security gurus preaching doom and gloom, you should be okay. In this case, I'm saying that sharing session IDs is generally okay, and I'm not aware of any security gurus preaching doom and gloom. So, session IDs hitting the wire is no (practically solvable) problem. If you have a very sensitive app, you should obviously use SSL, and you may want to invalidate them once in a while. Many sites do this (google invalidates biweekly (fair enough), paypal invalidates every time you breathe to the general annoyance of all, ebay every 24h (similarly ridiculous), et cetera). General Rule: Security does not trump user friendliness. Don't invalidate sessions unless you have a pressing reason to do so. If a tiny, rarely used part of your app is sensitive but the rest isn't, use time-sensitive servlets: Give servlets the time since the session was created and allow a servlet to say that this is no good, which should lead to a login screen. > b) Don't send sessionID as request parameters - or am I wrong here DO send sessionID as parameters. ALWAYS do this. The cookie is there ONLY for the benefit of the client GWT code so that it can fish the sessionID out of the cookie in order to survive reloads and browser quits. If we could tell the browser to stop sending the cookie along, we would. In practice you shouldn't do this (you CAN take down the cookie and add a window closing hook to put it back, but the window closing hook is more of a prayer / hopeful suggestion than something that gets reliably called). You could more reasonably take out the cookie right before you send a request and put it back right after if you're sufficiently paranoid, but there's no serious benefit here unless you also go for the other outside-of-the-norm maneuvre of cryptographically hiding the session ID. So, let me make this perfectly clear: Attempting to keep the session ID out of the hands of people listening on the line is technically possible but something you SHOULD NOT DO unless you are a security expert and/or in the mood to tinker and experiment. It's not something anybody really does right now, though being the first is nice. If you are a tinkerer / experimenter / guru. Not if you're just trying to get on with your project. The reason you, as a server, look ONLY at the session ID transfered in the BODY of the incoming request (instead of the cookie, which would also be there), is to avoid XSRF (a.k.a. seasurf a.k.a. Cross Site Request Forgery, see wikipedia) attacks. In order to properly protect against XSRF, you should also NOT use x-www-form-encoded as your wire format. Use JSON (add session ID as a key/value pair in the top-level map), GWT-RPC (Add it as a field in the class you are passing along the wire), or some non-x-www-form-encoded-fakable format of your own devices, if you have very weird requirements or some such. Don't use XML, obviously - as wire format it's ridiculous. It would be good if you are consistent with this mechanism (for JSON, always call it 'sessionID' and always transfer dictionaries, not arrays, and for GWT-RPC, make everything extend something simple that contains just a getSessionId() method). This way, you can write one generic session ID checker that passes the session ID onwards to your server framework's session system. That's a lot better than forcing every individual servlet to manually fish out the session ID and chat to the session system. It helps ensure that you don't forget to use this alternative session mechanism if you can somehow tell your framework's session system to not mess with cookies (neither write nor read them). Instead, your login servlet will manually generate one (e.g. HttpSession.newSession), send it along to your GWT code, and then your GWT code uses the GWT Cookie class to set the cookie. Similarly, it will retrieve the cookie via GWT's Cookies class, and send that right away to the server if its there (in its entrypoint). This comes back to the reason you're using the cookie in the first place: To let the session survive browser shutdowns and reloads. It's not a reliable authentication mechanism due to XSRF. > c) You could send sessionID as part of a, say, RPC payload object, but > it should be hashed or otherwise encrypted otherwise it's still easily > read by a determined black hat. However, nobody actually does this. In > any case encryption libraries available for java script are not > Mallory proof) Yes, entirely correct. Only SSL is mallory proof. There are some minor concerns about users reading out the cookies data off of a user's harddrive, but if that is compromised, usually their entire terminal is compromised, and *nothing* can protect against a compromised terminal, not even SSL + whatever shenanigans you can come up with. If SSL is not an option but you want to do something more that nobody else is doing, well, there's that experimental thing: remove the cookie and re-add it every time, consider not using cookies at all (forcing the user to re-login every time. I hope your office windows are rotten-fruit-proof, they'll be pissed), and instead of sending the session ID along, send only the first half of a very long session ID along, then take the entire payload (let's say, a JSON string), append the other half, hash it with SHA-512 or some such, then send the JSON string (sans latter half) + hash signature to the server. The server can use the first half to figure out what session this is for, and then verify the hash with the latter half. The latter half never hits the wire so Eve, even without SSL, is screwed. (You can insert your own version of this mechanism, this isn't the only way to safely do it). Mallory, on the other hand, just hacks your GWT code and skips this entire song and dance number. Again, DONT DO THIS unless you're feeling experimental. > d) The only bomb proof way to serious security (i.e. Mallory proof) is > via SSL. Correct. No amount of trickery will help there, because mallory can always take out the trickery as a man-in-the-middle. However, if the terminal is compromised, for example because some enterprising pissant stuffed a keylogger in the back, or your intelligence-challenged user thought it was a good idea to run an .exe file because the mail promised cute kittens, then all bets are off. Fortunately, for you, you cannot detect or fight this kind of attack using technology. The only defense is teaching your users, or giving your users a locked down computer, which I doubt is feasible :) The remainder of your replies are right on the money, and I apologize for being my usual facetious self. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
