Re: GWT Session management regardless of Servlet Container
No, it doesn't. Why it doesn't? How an attacker can obtain and pass our rpc-sessionId? -- 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.
Re: GWT Session management regardless of Servlet Container
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
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.comgoogle-web-toolkit%2bunsubscr...@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.comgoogle-web-toolkit%2bunsubscr...@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.
Re: GWT Session management regardless of Servlet Container
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.shaik...@gmail.com
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
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-toolkit@googlegroups.com
.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.comgoogle-web-toolkit%2bunsubscr...@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.comgoogle-web-toolkit%2bunsubscr...@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.comgoogle-web-toolkit%2bunsubscr...@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
Re: GWT Session management regardless of Servlet Container
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.comgoogle-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.
Re: GWT Session management regardless of Servlet Container
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.i...@gmail.com
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
GWT Session management regardless of Servlet Container
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.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GWT Session management regardless of Servlet Container
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.comgoogle-web-toolkit%2bunsubscr...@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.
