GWT Session management regardless of Servlet Container

[Philip Ives]

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.

}

}

}

[Sripathi Krishnan]

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 <phil...@gmail.com>

--

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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Abdullah Shaikh]

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

[Sripathi Krishnan]

Sure. You could just a header x-session-id and set its value appropriately. In your servlet, just check if the value matches what you get from HttpSession object.


--Sri

2010/1/4 Abdullah Shaikh <abdullah...@gmail.com>

[Philip Ives]

doesn't the first half of my if statement do the same thing as your
option 1? httpsession.getId().equals(sessionId)

I'm assuming all my rpcs take sessionId as a parameter (perhaps there
is a better way to do this? I'm looking at re-factoring to use the
command pattern.

when i login the user i pass back the sessionid via rpc to the client

On Dec 31 2009, 5:25 pm, Sripathi Krishnan

<sripathi.krish...@gmail.com> 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 <phil.i...@gmail.com>> I've done some searching around and I understand the warrants of

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>

[Sripathi Krishnan]

doesn't the first half of my if statement do the same thing as your
option 1? httpsession.getId().equals(sessionId)

No, it doesn't.
You should read up this article - http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications.

Assuming a user is logged in to your site (http://mywebsite.com). Now, an attacker sends a link like http://attacker.com in an email to your user. The html on attacker.com makes a post request to mywebsite.com.  In the above scenario, the browser will send the cookie to your website, and automatically assume that the user is logged in. That's the classical cross site scripting attack.

The important thing to remember is that the attacker doesn't have access to the cookie; he is just relying on the fact that the browser will send the cookie. But if you pass the the session id in your request, things will work fine. Browser won't automatically send it, and the attacker can't send it because he doesn't have access to it.

Option (2) works because attacker.com cannot make a XmlHttpRequest (Same Origin Policy). attacker.com can only use iframes/forms/images etc to make http requests, none of which can set a custom http header.

--Sri

2010/1/5 Philip Ives <phil...@gmail.com>

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Vitaliy Ryabukhin]

>> No, it doesn't.
Why it doesn't? How an attacker can obtain and pass our rpc-sessionId?