like adding security to ensure the clients session id can't be stolen by ether updating the sessionId thoughout the session. But that's really beyond this thread of just understanding what can be expected once a session is created.
On Oct 23, 1:21 am, Josh <[email protected]> wrote: > So I can count on getThreadLocalRequest().getSession().getId() to > always return the same value for every RPC call the client makes for > the life of the session. The server will somehow figure out that the > client who just logged in and was given a session Id, Is the same > person who is now requesting his user profile info. > > Sure a skilled hacker could somehow trick the server into getting > getThreadLocalRequest().getSession().getId() to return the same value > as the client they are pretending to be. But unless they already know > what the sessionId is on the server side they shouldn't be able to > compromise the server. > > So on the following RPC call after a login in which the client passes > the recently obtained SessionId to the server. On the server side I > can do a quick check > [code] > private boolean validateWithSessionId(String sessionId){ > //Create Session if one does not exist > HttpServletRequest request = this.getThreadLocalRequest(); > HttpSession session = request.getSession(); > > try { > if (sessionId == session.getId()) > return true; > return false; > } catch (Exception e) { > // TODO: handle exception > return false; > } > [/code] > So as long as I never give out a sessionId except after a login. > Always require this sessionId with every call then I've taken care of > most security issue. > > The part that confused me the most is when people would say you use > the sessionId to restore a session. I have yet to see where the server > would need a sessionId to figure what session was previously given to > the client. Or a session method that would take a session Id and then > any session.getAttribute("userName"); would return the correct user > instead of nothing afterwards. > > Thanks Thomas and Falcon. I think I understand it more next step would > be to tackle issues like > > On Oct 22, 10:53 am, Thomas Broyer <[email protected]> wrote: > > > > > > > > > On 22 oct, 16:15, Falcon <[email protected]> wrote: > > > > The web, in general, is stateless, and http is a stateless protocol. > > > The upshot of this is that every time you send a request to a web > > > server it has no idea who you are without some identifying piece of > > > information. > > > > So, once a session has been set on a server, that session has an ID. > > > The user has a cookie on their computer that contains the ID of that > > > session. Without that ID, the server has no idea what session to look > > > up, so if you call session.getAttribute("userId") without the client > > > sending a session ID, you wouldn't get back anything. Every request > > > the user makes to your server, they're sending across the cookie with > > > that session ID so that your server knows what session information to > > > look at. Keep in mind that there could be any number of users on an IP > > > address, so IPs can't be used for that sort of thing (not to mention > > > IPs can be spoofed, so if servers used IP addresses for that sort of > > > thing sessions could be hijacked extremely easily!) > > > > As far as rebooting their PC: that entirely depends on both your > > > server session and cookie settings and the user's cookie settings. The > > > cookie can be temporary so that as soon as they close their browser it > > > disappears, it can be effectively permanent (set to expire 1000+ years > > > into the future, for example) or anything between. You can set your > > > sessions on the server to expire as quickly as you like as well. If > > > the client's cookie goes away, they won't have the session ID to use > > > to call up that session. Similarly, if the session expires on the > > > server and thus is deleted, the user would be logged out even if they > > > still have the cookie. > > > > So that's why when you're sending RPC requests to your server, unless > > > those requests should be able to be made by the public in general, you > > > need some form of user identification/authentication on them. > > > Otherwise I can just produce my own RPC request to your server outside > > > of your app and perform any RPC request I want. > > > > There's quite a bit of reading on this topic, but hopefully that's a > > > decent overview to give you a bit better understanding of what's going > > > on. Feel free to ask more questions and I'll try to help. > > > The other thing to look at is Cross-site Request Forgery (CSRF), and > > this is why your session Id SHOULD be sent within the request (payload > > or request header, but *explicitly*, contrary to cookies which the > > browser will decide whether to send, and with which value). It doesn't > > mean you shouldn't use servlet sessions (with the cookie to relate the > > user to the HttpSession object), but that if you do you should at > > least *also* send the session ID explicitly in the request, and check > > on the server-side that it's the same as the session ID the servlet > > container will use (getThreadLocalRequest().getSession().getId()). > > You should also check if the session comes from the URL rather than a > > cookie to avoid session fixation attacks > > (isRequestedSessionIdFromURL): setting the session ID explicitly in > > both the URL and the request payload or headers so someone will start > > using *your* session (as the attacker), and then hope it'll stick (the > > server sending back a cookie for the session ID), the user doesn't > > notice, *and* it starts entering sensitive information (so you, as the > > attacker, can read it back). > > > With GWT-RPC, CSRF is fortunately harder to achieve, but not > > impossible. -- 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.
