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