Sorry Reiner, I wasn't being trying to be facetious. I just wanted to understand exactly what you are saying really. As I understand it so far:
a) Don't send sessionID as cookies - deliberately configure app server to stop it using cookies for tracking sessionIDs b) Don't send sessionID as request parameters - or am I wrong here (you say "instead lifting the session out of the parameters)? 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) d) The only bomb proof way to serious security (i.e. Mallory proof) is via SSL. I suppose my question is this really: Say you do not want to use SSL (apart from maybe initial log in), but you also don't really want to send session ID's that any old Eve (using your Mallory & Eve thing) can read falling off a log, it's not really clear to me what to if you don't do something like c). Reading your posts back in October last year: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/59f3aafcf4951523 my understanding is: 1) Unless you use SSL across the board you cannot defend against Mallory. However Mallory is rare. 2) Invest $60 in a SSL certificate and run your log-in/lost p/w stuff through SSL otherwise a determined Eve can get uid/pw and simply use the front door 3) To defend against Eve discovering the session, you need a procedure like the one you describe (e.g. key = sessionID + " " + counter + " " + SHA256_HASH(sessionBase,counter++); 4) from Eve's point of view, it doesn't really matter where (key = sessionID + " " + counter + " " + SHA256_HASH(sessionBase,counter++) is in the packet (request parameter, buried in RPC payload whatever) she will find it and either she can crack it or she can't. Therefore your point is (I think, and I appreciate you've been trying to explain this for months until you are blue in the face) there is no point at all in doing something like I was suggesting above for the simple reason that a) if the encryption of the session id is strong enough to defeat Eve, it doesn't matter where it goes in the packet, and b) if it isn't strong enough to defeat Eve, it equally doesn't matter where it goes in the packet. Forgive me if I'm being dense, Reinier, and my applogies if my previous comment offended you, it wasn't meant to. regards gregor On Nov 29, 11:29 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > You're asking me if some Reinier Approved algorithm would meet with my > approval? > > Uh, yes. > > I have a question for you, though: > > Does a gregor approved method of shooting a puppy meet with your > approval? If not, can you explain why? > > On Nov 28, 9:02 pm, gregor <[EMAIL PROTECTED]> wrote: > > > @Reinier > > > > gregor: What do you mean 'bad idea because the session ID would be > > > visible on the wire'? All session IDs are visible on the wire, unless > > > you set up a scheme where the client javascript does some hashing or > > > encryption. > > > Suppose I replaced: > > > sessionID = someSessionIDCookieGrabbingMethod(); > > > with: > > > sessionID = someReinierApprovedEncryptionAlgorithm(); > > > would this meet with your approval? If not can you explain why? > > > regards > > gregor > > > It's been floated as an idea many times on this forum, and > > > > it is certainly feasible, but its very much outside of the norm. > > > Virtually nobody on the entire web is doing this today. There are a > > > number of issues I don't really want to get into. Suffice to say: Yes, > > > doable. Yes, very cool. No, not standard or required by any stretch of > > > the imagination. Such a scheme would still be significantly less > > > secure than SSL, because it won't hold up to a man in the middle > > > attack (the man in the middle will just modify your GWT code to send > > > the password to his secret server in nigerussomania. > > > > On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > > > > > Hey everyone, > > > > > I have been working a while now on properly defending my GWT app > > > > against Cross Site Request Forgery (XRSF) with a minimal change in the > > > > code of the application itself. > > > > > My idea has been to create a new RPC call that will be the same from > > > > the programmers points of view as the normal, but which will add some > > > > value (a sessionID for instance) to the list of supplied parameters > > > > just before the call is send. Then, on the server side, the programmer > > > > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > > > > normal one. This secure version will simply remove the extra > > > > paramater, check it's validity and only execute the requested method > > > > if the authentication succeeds. > > > > > So far I have been able to subclass the RemoteServiceServlet (RSS) > > > > into the SRSS. It overrides the processCall(String payload) method to > > > > implement the verification (in my case the last argument, but that can > > > > easily be changed), thus working exactly the same as the normal RSS > > > > without any change needed in the code other than changing the extend. > > > > > The problem is that I really do not understand where I might add the > > > > code to modify the sending of the request client side. I have studied > > > > the RPC diagrams and almost everything I could find on the group > > > > concerning RPC, but I still do not understand what I need to change or > > > > override to create a custom RPC call. I have thought about making a > > > > subclass of the ServiceDefTarget so that the calling URL could be > > > > modified, but this is an interface and not a class, so is not going to > > > > work. > > > > > Does anyone have any idea's on this? > > > > > Patrick > > > > > PS: If I succeed at making something useful, I will create a package > > > > and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
