Regarding the 2 option for XSRF, passing a custom, static http header in every RPC request, can we pass the jsessionid itself as http header.
- Abdullah On Fri, Jan 1, 2010 at 3:55 AM, Sripathi Krishnan < [email protected]> wrote: > There are two use cases generally need to be solved - > > 1. Verify that the user is logged in. > 2. Ensure that this isn't a cross-site scripting (XSRF) attack. > > The code snippet you provide does take care of (1). However, it does not > guarantee against (2). > > There are a couple of ways to take care of XSRF, none of which require you > to abandon HttpSession. > > 1. Pass the jsessionid cookie value along with each rpc request. On the > server side, compare the jsessionid from request and from session. If they > are different, stop processing. > This isn't very difficult. You can make a custom RpcRequestBuilder > class, and append the jsessionid in the URL. The check on the server side > is > something like this - > if (request.getParameter("sessionid").equals(session.getId())) { > //everything okay > } > else { > //XSRF > } > 2. Pass a custom, static http header in every RPC request, and check > for the presence of the header in your RPC Servlet. > There is no known way of adding a custom header via any javascript code > other than a XmlHttpRequest, so this effectively rules out a XSRF. For a > short time period, GWT had this approach baked into RemoteServiceServlet, > but it has been removed from the current version. Not sure why they removed > it. > > None of the above two approaches forbid the use of container based session > management. So, if you want to use session management, go ahead and use it - > but just follow one of the approaches to prevent XSRF. > > > --Sri > > > 2009/12/31 Philip Ives <[email protected]> > > I've done some searching around and I understand the warrants of >> stateless applications. However login security always requires some >> state. >> >> Of course your application could use your containers session >> management and if your container can replication sessions across >> instances all the better. >> >> In some of the session management discussions on the GWT site as well >> as these forums there is talk about not relying on your container to >> identify the session ID because it could come from the cookie / header >> and that has cross site security implications which I follow. >> >> That all said getting the httpsession by context has been deprecated >> since 2.1 >> >> If you search this group with "session management" you'll find most >> of these discussions. >> >> If I anticipate that my container will handle session replication if i >> need it. Does doing something like this make sense and make sure that >> the container's session management is not using the cookie/header, and >> if it is, it doesn't matter: >> >> MyServiceImpl extends RemoteServiceServlet implements MyService { >> /** session id is passed in during service call from client. >> (perhapps tokenized */ >> public static getUserBySession(String sessionId) { >> HttpSession httpsession = this.getThreadLocalRequest().getSession >> (); >> if (httpsession.getId().equals(sessionId) && (Boolean) >> httpsession.getAttribute("Loggedin")) { >> //user is valid and logged in, session id checked against rpc >> value. >> >> } >> >> >> } >> >> } >> >> -- >> >> 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]<google-web-toolkit%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> >> > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- 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.
