Re: SecureRemoteService and Servlet. The battle against XSRF.
On Dec 3, 3:57 am, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > jhulford, from what I understand, cookies are sent in the header as > well and that is whole reason they are vulnerable to XSRF, so setting > some header would seem to me like not to solve the problem. Your > second post was very useful, I had not seen the second article with > all the info and it gave me a lot to think about. Thanks. See the paragraph below I copied from the article. It explains why you may want to send the header - it's really the same strategy as sending the identifier in the parameter list but, in my opinion, using the header strategy makes it easier to do the authorization transparently to your service layer (ie. you don't have to put session params in all your service call APIs). Besides, putting your session identifier in the parameter list is just as vulnerable to being manipulated as a header. If someone's man-in-the-middle'd you it's not going to matter where you're sending the session identifier, they'll be able to get at it. The way I understand it the only real defense against MITM is to use strong encryption. "An easy way to prevent this is to use JavaScript to copy the cookie value and submit it as form data along with your XMLHTTPRequest call. Since the browser's Same-Origin Policy will prevent a third-party site from accessing the cookies from your site, only your site can retrieve your cookie. By submitting the value of the cookie along with the request, your server can compare the actual cookie value with the copy you included; if they don't match, your server knows that the request is an XSRF attempt. Simply put, this technique is a way of requiring the code that made the request to prove that it has access to the session cookie." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Patrick: I understand what you are trying to do, as i just went through the same headache myself. It appears that the GWT team is working on a similar approach for a future version: http://code.google.com/p/google-web-toolkit/wiki/RpcAuth so any solution we come up with today will be short-lived. Has anybody considered overriding the GWT Remote Service Proxy generator to inject the session id into the RPC payload? Reinier: your objections make sense to me, although they are more applicable to traditional server-side apps than to "invisible" RPC requests. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hey everyone, thanks a bunch for all the replies again. Replies inline and questions at the end. Gregor, with everything that I have heard thus far, that Command pattern is looking better and better, even though it will still be a lot of work to properly implement. jhulford, from what I understand, cookies are sent in the header as well and that is whole reason they are vulnerable to XSRF, so setting some header would seem to me like not to solve the problem. Your second post was very useful, I had not seen the second article with all the info and it gave me a lot to think about. Thanks. quentin, what I am trying to is explained in the end of my post here, perhaps reading it will make sense to you then. Reiner, thanks once again for brightening the start of my workday with the notion that someone else on this planet can explain things to people with even more sarcasm then I can. :) Your post is the one that really got me a bit down though. What you say is that you see no feasable way to do what I am trying to do, and as Gregor said, you seem to know your stuff, and I therefore seem to slowly lose hope in succeeding quickly with this. To everyone: We have discussed the pro's and con's of many methods now, but let's try to focus on what I initially was trying to ask. :) I am trying to make something that will AUTOMATICALLY add a sessionID into the PAYLOAD of ANY RPC call sent in my app. This sessionID will AUTOMATICALLY be checked server side, and if okay it will be stripped. The result would ideally be that by extending two different classes (one server side and one client side) the programmer would have full XSRF protection without modifying ANYTHING else in his code. Server side this can be done by subclassing the RemoteServiceServlet and overriding the processCall method, I have done this. My problem is that I really cannot find what I should capture or extend on the client side. I have this vague feeling that is because this is all to deeply hidden away in the GWT itself, but I cannot verify this in any way. I really hope that we can fix this and that our solution will help every programmer that has not thought about XSRF with his or her GWT app to make their app secure with minimal effort. (like me, I guess ;) Patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
quentin: URLs aren't designed to be protected. At all. Cookies aren't exactly locked away in Fort Knox on your harddrive, but browsers at least have the good sense to understand that they shouldn't send arbitrary pieces in the cookiefile to arbitrary servers. Not so for URLs. To wit: 1) 'aggregator' websites such as Digg, Reddit, stumbleupon, and even just del.ico.us or just mailing a link around because you want to show 'something cool' to a friend, always grab the entire URL and spill this out to the world at large. This is obviously really really bad. One 'fix' is to make these sessions time out fast, but this annoys users, and having your account accessible by anyone following a story on an aggregator for 'just half an hour' is still pretty bad. 2) Referral. When browsing to another domain, your browser will add a Referrer: header which contains the URL that the user came from. This is handy for analysis flow on your own site, and to figure out where people are coming from when visiting your site. If you run a website and you're using google analytics or some other traffic analyser, you may have noticed a '% of traffic from google' indicator. This thing works by checking how many incoming requests have a Referrer: (www\.)? google\.com.* - this referrer system does not discriminate and will happily toss over the ENTIRE URL, which would include your session. I could -easily- make a webserver that'll check if it looks like there's a session ID in a URL, then report it and the website via chat to me, so I can quickly see if I can log in as this person. 3) Bookmarks. web-based bookmarking was covered in #1, but even a local bookmark is relatively bad, because in general bookmarks are far easier to leak to another person than your cookiefile. sharing bookmarks is actively encouraged by many browsers. No user except a real geek would cut his URL down to eliminate the session ID from it (and even more pathetic, if this geek does do that, using the bookmark is near useless because he'll have to log in again. d'oh). 4) It's a giant sore thumb that both says: Geez, I'm ugly, and: OMG, I have absolutely zip squat idea about web security, so whatever info you give to me, consider it yelled from the rooftops. Boy, my webmaster is a thick headed clot. Most other security leaks aren't nearly as visible, which isn't much comfort, but it does count for a little that this one is so obvious. Just look at the address bar. NB: Yes, yes, the official java servlet spec, even the very latest version, officially declares that URL rewriting is amongst the strategies. Sun evidently considers background compatibility with dangerous code more important than security, which, to say it mildly, / annoys/ me just a tad. On Dec 2, 2:21 pm, quentin <[EMAIL PROTECTED]> wrote: > Reiner, > > Thanks for the reply. Call me naive/ignorant/stupid/whatever but what > are the security risks associated with using ";jsessionid"? The reason > i ask is because GWT cookie support in safari 4 appears completely > broken. (It's actually not GWT's fault. in safari 4, the js statement > "document.cookie = " doesn't seem to work). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Yes, you could definitely do that to merely access your session but
that doesn't do anything to help prevent XSRF. Here's a great article
all about this which includes what I mentioned earlier about sending
the identifier as a header.
http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications
The article is a little dated since you can now get at the Request or
RequestBuilder objects for the GWT-RPC requests and set the headers.
This page explains how to get at the Async's underlying Request and
RequestBuilder objects
http://vinaytech.wordpress.com/2008/09/28/google-web-toolkit-and-client-server-communications/.
On Dec 1, 5:26 pm, jossey <[EMAIL PROTECTED]> wrote:
> Hmm.. I ve a stupid question now..
> Can't we use RemoteServiceServlet.getThreadLocalRequest().getSession()
> to get the current session?
> I found 'using the session' working in GWT 1.5.
>
> On Dec 1, 9:31 am, jhulford <[EMAIL PROTECTED]> wrote:
>
> > Another thing you can do in order to always send your session
> > identifier as part of your request is use the RequestBuilder and add
> > the identifier as a request header.
>
> > RequestBuilder requestBuilder = new RequestBuilder("POST", "/
> > myServletUrl");
> > RequestBuilder.setHeader("X-Session-Id", mySessionIdFromCookie);
>
> > On Dec 1, 8:31 am, gregor <[EMAIL PROTECTED]> wrote:
>
> > > Hi Patrick,
>
> > > I think you probably want to call the static async instance according
> > > to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
> > > otherwise you might get confused as to what's going on
>
> > > > --- Code, I hope this formats reasonably in the post. ---
> > > > public interface SecureRemoteService extends RemoteService {
>
> > > > /**
> > > > * Utility/Convenience class.
> > > > * Use SecureRemoteService.Async.getInstance() to access static
> > > > instance of IpsvRmapServiceAsync
> > > > */
> > > > public static class SecureRemoteServiceAsync {
> > > > private static Async ourInstance = null;
>
> > > > public static synchronized SecureRemoteServiceAsync
> > > > getInstance() {
> > > > if (ourInstance == null) {
> > > > ourInstance =
> > > > (SecureRemoteServiceAsync) GWT.create(SecureRemoteService.class);
> > > > }
> > > > return ourInstance;
> > > > }
>
> > > > public void setServiceEntryPoint(String entryPoint) {
> > > > // This is where the magic happens.
> > > > ((ServiceDefTarget)
> > > > ourInstance).setServiceEntryPoint
> > > > (GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
> > > > ());
> > > > }
>
> > > > private String getSessionID() {
> > > > // Do stuff to get sessionID
> > > > return "SessionID";
> > > > }
> > > > }}
>
> > > > --- End of code ---
>
> > > Then you use it like so in code:
>
> > > SecureRemoteServiceAsync async
> > > = SecureRemoteServiceAsync.App.getInstance(); //
> > > the URL will now have the SessionID param
> > > async.someMethod(param, new secureRemoteServiceCallback());
>
> > > Note that this does not work across the board, you have to do this
> > > once for each RPC service separately (i.e. once per RPC service
> > > interface declared), but if you extend RemoteServiceServlet and
> > > override the processCall() method to grab and check sesionID
> > > parameter, then use this extended RemoteServiceServlet this for all
> > > your RPC services, they will all validate the sessionID.
>
> > > I guess it's a matter of taste and situation, but I think I prefer the
> > > second method (the Command pattern variation) becasue a) if you want
> > > to change the way you handle this session thing, you just do it the
> > > Payload base class and the extended RemoteServiceServlet.processCall
> > > (), you do not have to change all your RPC Async interfaces and b)
> > > this Payload pattern is useful for a lot of other reasons in handling
> > > objects over the wire. I think it deals with the XSRF issue too (but
> > > I'm sure Reinier will nail me to wall again if wrong!)
>
> > > regards
> > > gregor
>
> > > > From what I can see, this should work if the interface extends the
> > > > SecureRemoteService instead of the normal one. However, to properly
> > > > create an instance of this class, the programmer now has to do
> > > > something different from the normal procedure. Instead of calling the
> > > > normal GWT.create(someService.class) and casting it to the Async
> > > > version, he has to call on GWT.create(someService.Async.class). This
> > > > means he has to modify all of his proxy creation statements as well.
>
> > > > Is there any way to get around this?
>
> > > > Thanks, Patrick
>
> > > > PS
Re: SecureRemoteService and Servlet. The battle against XSRF.
Reiner, Thanks for the reply. Call me naive/ignorant/stupid/whatever but what are the security risks associated with using ";jsessionid"? The reason i ask is because GWT cookie support in safari 4 appears completely broken. (It's actually not GWT's fault. in safari 4, the js statement "document.cookie = " doesn't seem to work). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Answers to gregor, Patrick, and quentin in this post.
Hey gregor -
some coward has probably taken exception to some light hearted ribbing
and instead of either playing ball or doing something vaguely
constructive, such as asking Sumit to protect his honour for him, he
instead did a search for my name to vote everything I've recently
written a 1-star, presumably because this act of revenge makes him or
her feel better. Chances are these posts were voted on without even
reading them. I therefore doubt it's got anything to do with my
security advice itself. Possibly the way I've been expressing it.
This certainly isn't the first time it happened.
Patrick:
Mea culpa - for some reason I was thinking that the objects tossed
across the wire had to wrapped in RPC interfaces and '-Async' classes.
Its actually the servlets that have to be. I don't see an easy way to
generify this. Seems like adding 'sessionID' as a parameter to -every-
-single- RFC-accessible method is required to make this work right. I
would at least make an easy method to fish the sessionID out of a
cookie+cache it on the client, and I'd make an easy method on the
server side to check it.
Client:
public class XSRF {
private static String sessionId;
public static String getSessionId() {
if ( sessionId == null ) sessionId = Cookies.getCookie
("jsessionid");
//the actual name of the cookie depends on your web stack.
//Just get all cookies and print their names to figure this
out, then hardcode it.
}
}
and on the server, add a method that does what I'm going to answer to
quentin:
quentin:
There's a slight risk you forget to check. It would certainly be an
excellent plan if your webstack supports plugging into it, adding that
check. (or if it doesn't, just hack it in - all hail Open Source as
the one true way for libraries). For reasons that aren't too
interesting, the apps I've written so far had other session
constraints which meant I re-invented the wheel anyway. However, I did
some checking and it turns out your strategy seems easiest - the
latest servlet spec makes it rather hard to query the session system
with a given ID.
To be a bit more verbose:
HttpSession session = request.getSession();
if ( !session.isNew() ) {
if ( !session.getId().equals
(sessionIDPassedInExplicitlyBySender) ) {
//XSRF detected.
response.sendError(response.SC_FORBIDDEN, "Whups. If you're
seeing this, please contact us.");
return;
}
}
jossey: Reread the entire thread. The servlet spec's own session
system is spectacularly stupid. It is either XSRF-unsafe and uses
cookies, or it is blatantly unsafe and stuffs session IDs in the URL
(I *STILL* see this in modern webapps - check for ;jessionid appended
to the URL, bizarre considering that security gurus have explained the
problem with this approach for over 5 years now). If it does use
cookies, it won't protect against XSRF, basically because you can't do
that without relying on javascript. Fortunately, using GWT means
you've already accepted that your users MUST have javascript up, so we
GWT users can solve XSRF the easy way, with javascript.
On Dec 1, 6:22 pm, gregor <[EMAIL PROTECTED]> wrote:
> Someone seems to disapprove of Reinier's views here and appears to
> have awarded a "poor" rating to each of his contributions to this
> thread. This is presumably calculated to deter the community from
> taking what he says seriously. For my part, especially in the light of
> the many other contributions he has made to this group on the subject
> of security, I would comment Reinier has almost certainly forgotten
> more than I have ever known about web security.
>
> Now one thing I could do is add an excellent rating here to each of
> his posts to balance things up, but that's just playing silly buggers,
> isn't it. Teenage/crank YouTube stuff.
>
> So whoever you are, why don't you state your case openly? I'd guess
> Reinier himself doesn't give two hoots about this (and probably
> wouldn't admit it if he did) but I do not think the community is best
> served by this sort of shenanigans. For the little I myself know about
> web and network security, Reinier's posts chime right in with it. If
> you think he's wrong, off the wall or something, then explain - oh,
> and at something even half approaching the detail.
>
> On Dec 1, 2:31 pm, jhulford <[EMAIL PROTECTED]> wrote:
>
> > Another thing you can do in order to always send your session
> > identifier as part of your request is use the RequestBuilder and add
> > the identifier as a request header.
>
> > RequestBuilder requestBuilder = new RequestBuilder("POST", "/
> > myServletUrl");
> > RequestBuilder.setHeader("X-Session-Id", mySessionIdFromCookie);
>
> > On Dec 1, 8:31 am, gregor <[EMAIL PROTECTED]> wrote:
>
> > > Hi Patrick,
>
> > > I think you probably want to call the static async instance according
> > > to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
> > > otherwise yo
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hmm.. I ve a stupid question now..
Can't we use RemoteServiceServlet.getThreadLocalRequest().getSession()
to get the current session?
I found 'using the session' working in GWT 1.5.
On Dec 1, 9:31 am, jhulford <[EMAIL PROTECTED]> wrote:
> Another thing you can do in order to always send your session
> identifier as part of your request is use the RequestBuilder and add
> the identifier as a request header.
>
> RequestBuilder requestBuilder = new RequestBuilder("POST", "/
> myServletUrl");
> RequestBuilder.setHeader("X-Session-Id", mySessionIdFromCookie);
>
> On Dec 1, 8:31 am, gregor <[EMAIL PROTECTED]> wrote:
>
> > Hi Patrick,
>
> > I think you probably want to call the static async instance according
> > to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
> > otherwise you might get confused as to what's going on
>
> > > --- Code, I hope this formats reasonably in the post. ---
> > > public interface SecureRemoteService extends RemoteService {
>
> > > /**
> > > * Utility/Convenience class.
> > > * Use SecureRemoteService.Async.getInstance() to access static
> > > instance of IpsvRmapServiceAsync
> > > */
> > > public static class SecureRemoteServiceAsync {
> > > private static Async ourInstance = null;
>
> > > public static synchronized SecureRemoteServiceAsync
> > > getInstance() {
> > > if (ourInstance == null) {
> > > ourInstance = (SecureRemoteServiceAsync)
> > > GWT.create(SecureRemoteService.class);
> > > }
> > > return ourInstance;
> > > }
>
> > > public void setServiceEntryPoint(String entryPoint) {
> > > // This is where the magic happens.
> > > ((ServiceDefTarget)
> > > ourInstance).setServiceEntryPoint
> > > (GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
> > > ());
> > > }
>
> > > private String getSessionID() {
> > > // Do stuff to get sessionID
> > > return "SessionID";
> > > }
> > > }}
>
> > > --- End of code ---
>
> > Then you use it like so in code:
>
> > SecureRemoteServiceAsync async
> > = SecureRemoteServiceAsync.App.getInstance(); //
> > the URL will now have the SessionID param
> > async.someMethod(param, new secureRemoteServiceCallback());
>
> > Note that this does not work across the board, you have to do this
> > once for each RPC service separately (i.e. once per RPC service
> > interface declared), but if you extend RemoteServiceServlet and
> > override the processCall() method to grab and check sesionID
> > parameter, then use this extended RemoteServiceServlet this for all
> > your RPC services, they will all validate the sessionID.
>
> > I guess it's a matter of taste and situation, but I think I prefer the
> > second method (the Command pattern variation) becasue a) if you want
> > to change the way you handle this session thing, you just do it the
> > Payload base class and the extended RemoteServiceServlet.processCall
> > (), you do not have to change all your RPC Async interfaces and b)
> > this Payload pattern is useful for a lot of other reasons in handling
> > objects over the wire. I think it deals with the XSRF issue too (but
> > I'm sure Reinier will nail me to wall again if wrong!)
>
> > regards
> > gregor
>
> > > From what I can see, this should work if the interface extends the
> > > SecureRemoteService instead of the normal one. However, to properly
> > > create an instance of this class, the programmer now has to do
> > > something different from the normal procedure. Instead of calling the
> > > normal GWT.create(someService.class) and casting it to the Async
> > > version, he has to call on GWT.create(someService.Async.class). This
> > > means he has to modify all of his proxy creation statements as well.
>
> > > Is there any way to get around this?
>
> > > Thanks, Patrick
>
> > > PS: Graag gedaan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Reinier, Why do you advocate rewriting your web stack's session management when you could just as easily let it continue to use the cookie as long as you validate that it matches the sessionid passed up via the parameter list? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Someone seems to disapprove of Reinier's views here and appears to
have awarded a "poor" rating to each of his contributions to this
thread. This is presumably calculated to deter the community from
taking what he says seriously. For my part, especially in the light of
the many other contributions he has made to this group on the subject
of security, I would comment Reinier has almost certainly forgotten
more than I have ever known about web security.
Now one thing I could do is add an excellent rating here to each of
his posts to balance things up, but that's just playing silly buggers,
isn't it. Teenage/crank YouTube stuff.
So whoever you are, why don't you state your case openly? I'd guess
Reinier himself doesn't give two hoots about this (and probably
wouldn't admit it if he did) but I do not think the community is best
served by this sort of shenanigans. For the little I myself know about
web and network security, Reinier's posts chime right in with it. If
you think he's wrong, off the wall or something, then explain - oh,
and at something even half approaching the detail.
On Dec 1, 2:31 pm, jhulford <[EMAIL PROTECTED]> wrote:
> Another thing you can do in order to always send your session
> identifier as part of your request is use the RequestBuilder and add
> the identifier as a request header.
>
> RequestBuilder requestBuilder = new RequestBuilder("POST", "/
> myServletUrl");
> RequestBuilder.setHeader("X-Session-Id", mySessionIdFromCookie);
>
> On Dec 1, 8:31 am, gregor <[EMAIL PROTECTED]> wrote:
>
> > Hi Patrick,
>
> > I think you probably want to call the static async instance according
> > to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
> > otherwise you might get confused as to what's going on
>
> > > --- Code, I hope this formats reasonably in the post. ---
> > > public interface SecureRemoteService extends RemoteService {
>
> > > /**
> > > * Utility/Convenience class.
> > > * Use SecureRemoteService.Async.getInstance() to access static
> > > instance of IpsvRmapServiceAsync
> > > */
> > > public static class SecureRemoteServiceAsync {
> > > private static Async ourInstance = null;
>
> > > public static synchronized SecureRemoteServiceAsync
> > > getInstance() {
> > > if (ourInstance == null) {
> > > ourInstance = (SecureRemoteServiceAsync)
> > > GWT.create(SecureRemoteService.class);
> > > }
> > > return ourInstance;
> > > }
>
> > > public void setServiceEntryPoint(String entryPoint) {
> > > // This is where the magic happens.
> > > ((ServiceDefTarget)
> > > ourInstance).setServiceEntryPoint
> > > (GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
> > > ());
> > > }
>
> > > private String getSessionID() {
> > > // Do stuff to get sessionID
> > > return "SessionID";
> > > }
> > > }}
>
> > > --- End of code ---
>
> > Then you use it like so in code:
>
> > SecureRemoteServiceAsync async
> > = SecureRemoteServiceAsync.App.getInstance(); //
> > the URL will now have the SessionID param
> > async.someMethod(param, new secureRemoteServiceCallback());
>
> > Note that this does not work across the board, you have to do this
> > once for each RPC service separately (i.e. once per RPC service
> > interface declared), but if you extend RemoteServiceServlet and
> > override the processCall() method to grab and check sesionID
> > parameter, then use this extended RemoteServiceServlet this for all
> > your RPC services, they will all validate the sessionID.
>
> > I guess it's a matter of taste and situation, but I think I prefer the
> > second method (the Command pattern variation) becasue a) if you want
> > to change the way you handle this session thing, you just do it the
> > Payload base class and the extended RemoteServiceServlet.processCall
> > (), you do not have to change all your RPC Async interfaces and b)
> > this Payload pattern is useful for a lot of other reasons in handling
> > objects over the wire. I think it deals with the XSRF issue too (but
> > I'm sure Reinier will nail me to wall again if wrong!)
>
> > regards
> > gregor
>
> > > From what I can see, this should work if the interface extends the
> > > SecureRemoteService instead of the normal one. However, to properly
> > > create an instance of this class, the programmer now has to do
> > > something different from the normal procedure. Instead of calling the
> > > normal GWT.create(someService.class) and casting it to the Async
> > > version, he has to call on GWT.create(someService.Async.class). This
> > > means he has to modify all of his proxy creation statements as well.
>
> > > Is there any
Re: SecureRemoteService and Servlet. The battle against XSRF.
Another thing you can do in order to always send your session
identifier as part of your request is use the RequestBuilder and add
the identifier as a request header.
RequestBuilder requestBuilder = new RequestBuilder("POST", "/
myServletUrl");
RequestBuilder.setHeader("X-Session-Id", mySessionIdFromCookie);
On Dec 1, 8:31 am, gregor <[EMAIL PROTECTED]> wrote:
> Hi Patrick,
>
> I think you probably want to call the static async instance according
> to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
> otherwise you might get confused as to what's going on
>
>
>
>
>
> > --- Code, I hope this formats reasonably in the post. ---
> > public interface SecureRemoteService extends RemoteService {
>
> > /**
> > * Utility/Convenience class.
> > * Use SecureRemoteService.Async.getInstance() to access static
> > instance of IpsvRmapServiceAsync
> > */
> > public static class SecureRemoteServiceAsync {
> > private static Async ourInstance = null;
>
> > public static synchronized SecureRemoteServiceAsync
> > getInstance() {
> > if (ourInstance == null) {
> > ourInstance = (SecureRemoteServiceAsync)
> > GWT.create(SecureRemoteService.class);
> > }
> > return ourInstance;
> > }
>
> > public void setServiceEntryPoint(String entryPoint) {
> > // This is where the magic happens.
> > ((ServiceDefTarget)
> > ourInstance).setServiceEntryPoint
> > (GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
> > ());
> > }
>
> > private String getSessionID() {
> > // Do stuff to get sessionID
> > return "SessionID";
> > }
> > }}
>
> > --- End of code ---
>
> Then you use it like so in code:
>
> SecureRemoteServiceAsync async
> = SecureRemoteServiceAsync.App.getInstance(); //
> the URL will now have the SessionID param
> async.someMethod(param, new secureRemoteServiceCallback());
>
> Note that this does not work across the board, you have to do this
> once for each RPC service separately (i.e. once per RPC service
> interface declared), but if you extend RemoteServiceServlet and
> override the processCall() method to grab and check sesionID
> parameter, then use this extended RemoteServiceServlet this for all
> your RPC services, they will all validate the sessionID.
>
> I guess it's a matter of taste and situation, but I think I prefer the
> second method (the Command pattern variation) becasue a) if you want
> to change the way you handle this session thing, you just do it the
> Payload base class and the extended RemoteServiceServlet.processCall
> (), you do not have to change all your RPC Async interfaces and b)
> this Payload pattern is useful for a lot of other reasons in handling
> objects over the wire. I think it deals with the XSRF issue too (but
> I'm sure Reinier will nail me to wall again if wrong!)
>
> regards
> gregor
>
>
>
> > From what I can see, this should work if the interface extends the
> > SecureRemoteService instead of the normal one. However, to properly
> > create an instance of this class, the programmer now has to do
> > something different from the normal procedure. Instead of calling the
> > normal GWT.create(someService.class) and casting it to the Async
> > version, he has to call on GWT.create(someService.Async.class). This
> > means he has to modify all of his proxy creation statements as well.
>
> > Is there any way to get around this?
>
> > Thanks, Patrick
>
> > PS: Graag gedaan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hi Patrick,
I think you probably want to call the static async instance according
to usual RPC protocol, i.e. in this case SecureRemoteServiceAsync,
otherwise you might get confused as to what's going on
>
> --- Code, I hope this formats reasonably in the post. ---
> public interface SecureRemoteService extends RemoteService {
>
> /**
> * Utility/Convenience class.
> * Use SecureRemoteService.Async.getInstance() to access static
> instance of IpsvRmapServiceAsync
> */
> public static class SecureRemoteServiceAsync {
> private static Async ourInstance = null;
>
> public static synchronized SecureRemoteServiceAsync
> getInstance() {
> if (ourInstance == null) {
> ourInstance = (SecureRemoteServiceAsync)
> GWT.create(SecureRemoteService.class);
> }
> return ourInstance;
> }
>
> public void setServiceEntryPoint(String entryPoint) {
> // This is where the magic happens.
> ((ServiceDefTarget) ourInstance).setServiceEntryPoint
> (GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
> ());
> }
>
> private String getSessionID() {
> // Do stuff to get sessionID
> return "SessionID";
> }
> }}
>
> --- End of code ---
Then you use it like so in code:
SecureRemoteServiceAsync async
= SecureRemoteServiceAsync.App.getInstance(); //
the URL will now have the SessionID param
async.someMethod(param, new secureRemoteServiceCallback());
Note that this does not work across the board, you have to do this
once for each RPC service separately (i.e. once per RPC service
interface declared), but if you extend RemoteServiceServlet and
override the processCall() method to grab and check sesionID
parameter, then use this extended RemoteServiceServlet this for all
your RPC services, they will all validate the sessionID.
I guess it's a matter of taste and situation, but I think I prefer the
second method (the Command pattern variation) becasue a) if you want
to change the way you handle this session thing, you just do it the
Payload base class and the extended RemoteServiceServlet.processCall
(), you do not have to change all your RPC Async interfaces and b)
this Payload pattern is useful for a lot of other reasons in handling
objects over the wire. I think it deals with the XSRF issue too (but
I'm sure Reinier will nail me to wall again if wrong!)
regards
gregor
>
> From what I can see, this should work if the interface extends the
> SecureRemoteService instead of the normal one. However, to properly
> create an instance of this class, the programmer now has to do
> something different from the normal procedure. Instead of calling the
> normal GWT.create(someService.class) and casting it to the Async
> version, he has to call on GWT.create(someService.Async.class). This
> means he has to modify all of his proxy creation statements as well.
>
> Is there any way to get around this?
>
> Thanks, Patrick
>
> PS: Graag gedaan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hey Reinier,
I am happy to hear that you agree with my approach so far (and even
use it yourself). Since I will only use GWT to communicate with the
app on the server I see no reason to adopt JSON, so were almost there.
Problem here is that I still need somewhere to add that sessionID into
the request from the client to the server. I have to admit that my
basic Java knowledge now seems to fail somehow here. I have attempted
to use the method suggested by Gregor earlier in this thread, however,
I can't figure it out.
>From what I can figure out about the code from Gregor one would
subclass (or subinterface I guess) the interface of the RemoteService
into the SecureRemoteService for instance. However, I do not
understand how to proceed from there.
I think I modified the example enough to show how far my knowledge
goes right now, but there are some issues with my idea: First the code
example:
--- Code, I hope this formats reasonably in the post. ---
public interface SecureRemoteService extends RemoteService {
/**
* Utility/Convenience class.
* Use SecureRemoteService.Async.getInstance() to access static
instance of IpsvRmapServiceAsync
*/
public static class Async {
private static Async ourInstance = null;
public static synchronized Async getInstance() {
if (ourInstance == null) {
ourInstance = (Async)
GWT.create(SecureRemoteService.class);
}
return ourInstance;
}
public void setServiceEntryPoint(String entryPoint) {
// This is where the magic happens.
((ServiceDefTarget) ourInstance).setServiceEntryPoint
(GWT.getModuleBaseURL() + entryPoint + "?sessionID=" + getSessionID
());
}
private String getSessionID() {
// Do stuff to get sessionID
return "SessionID";
}
}
}
--- End of code ---
>From what I can see, this should work if the interface extends the
SecureRemoteService instead of the normal one. However, to properly
create an instance of this class, the programmer now has to do
something different from the normal procedure. Instead of calling the
normal GWT.create(someService.class) and casting it to the Async
version, he has to call on GWT.create(someService.Async.class). This
means he has to modify all of his proxy creation statements as well.
Is there any way to get around this?
Thanks, Patrick
PS: Graag gedaan.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Your plan to use an interface extending RemoteService to be consistent
in how you read the sessionID out of the request body and not the
cookie sounds excellent.
SSL does not protect against XSRF by itself. However, it does turn
moot the general issue of having session IDs hit the line. The long
talks about attempting to hide the sessionID by hiding the cookie and
using some whacky crypto scheme are experimental craziness without
SSL, and if you're already using SSL, utterly pointless.
In other words, SSL + your XSRF protection plan = security sweetness.
I run my website that way. (tipit.to)
You could hack in some sort of exception-over-JSON protocol, where you
build a custom class in between the HttpServlet and YourOwnServlets
class inheritance, which makes it easier to output JSON (for example
by allowing you to output a hashmap), as well as wrapping the actual
doGet()/doPost() calls (by overriding service()) in try/catch, and
having a standard way of conveying the exception to the client. e.g:
{ "error": true, "errorType": "java.io.FileNotFoundException",
"errorMessage": "/foo/bar" }
Going JSON with your API isn't really "better" than using GWT-RPC
unless you have very specific needs (such as: I'll be accessing my
servlets from something other than GWT as well), so only do this if
you really really need it.
One last security note on tossing exceptions across the line
automatically: That can be a security leak, in the sense that you tend
not to think about the exception when considering the type of data
that a servlet will send out onto the internet. It's rare that useful
info leaks out that way, but it does happen, and often it helps a
cracker determine fruitful attacks. Unless you run a very security-
sensitive app, I would accept the risk, but think about what info
might be available in an exception, and if its really bad, do
something about it. Example:
You need to read the password to the database off of disk, because you
use some horribly outdated database layer. The filename contains the
name of the db server and db name. This is info a cracker didn't have
before, but if that file doesn't exist or can't be read, now he does,
because FileNotFoundException, IIRC, has as message the filename. So,
the cracker sees /dbPasswords/localhost_1234_myServerDB or some such.
More info than he had. If he's found a different app on your site that
can be coerced into returning any given file anywhere on the system,
but not directory listings, he now has his puzzle complete and knows
the location of your db and the password. Again - don't abandon the
idea of swapping exceptions across the wire, just try to be aware that
it happens and that exceptions thrown by your servlet is essentially
public info.
NB: Bedankt :)
On Dec 1, 9:58 am, Patrick Ratelband <[EMAIL PROTECTED]> wrote:
> Hey everyone,
>
> thanks for the big replies. There is a lot of info in there, but I
> still have some questions.
>
> I understand that Mallory will always be a problem and that Eve might
> be one, however, defeating them is not part of what I want to do. The
> only thing I want to guard against are XSRF attacks. I understand that
> to prevent these I must put some identifier (let's use sessionID) and
> store it in a cookie to survive browser reload and I must pass it
> inside my GWT RPC request and not rely on the cookie in the header.
>
> So far so good, this is exactly what I am implementing right now.
>
> Gregor suggested that I create an interface that would extend the
> RemoteService, this is along the lines of what I was thinking as it
> would make the whole XSRF system transparent to the programmer, I have
> also understood from the later posts between you and Reinier that the
> visibility of the actual sessionID on the wire is not a problem here,
> so is there any substantial objection to use this approach?
>
> Shawn suggested I use his implementation with JSON, however, I have
> read the readme and the fact that exceptions are not thrown over the
> line is too big of a drawback for me as I use these in the app
> already.
>
> Reiner, you really seem to know your stuff, thank you for your
> clarifying posts and your enjoyable cynical take on the world. I think
> I understand what you are saying.
>
> Last question, would using SSL (which will be implemented on the
> server within a week or two) also prevent XSRF? From what I have read,
> I cannot draw a conclusion one way or the other.
>
> With thanks, Patrick
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hey everyone, thanks for the big replies. There is a lot of info in there, but I still have some questions. I understand that Mallory will always be a problem and that Eve might be one, however, defeating them is not part of what I want to do. The only thing I want to guard against are XSRF attacks. I understand that to prevent these I must put some identifier (let's use sessionID) and store it in a cookie to survive browser reload and I must pass it inside my GWT RPC request and not rely on the cookie in the header. So far so good, this is exactly what I am implementing right now. Gregor suggested that I create an interface that would extend the RemoteService, this is along the lines of what I was thinking as it would make the whole XSRF system transparent to the programmer, I have also understood from the later posts between you and Reinier that the visibility of the actual sessionID on the wire is not a problem here, so is there any substantial objection to use this approach? Shawn suggested I use his implementation with JSON, however, I have read the readme and the fact that exceptions are not thrown over the line is too big of a drawback for me as I use these in the app already. Reiner, you really seem to know your stuff, thank you for your clarifying posts and your enjoyable cynical take on the world. I think I understand what you are saying. Last question, would using SSL (which will be implemented on the server within a week or two) also prevent XSRF? From what I have read, I cannot draw a conclusion one way or the other. With thanks, Patrick --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Replies inline... On Nov 29, 2:08 pm, gregor <[EMAIL PROTECTED]> wrote: > > a) Don't send sessionID as cookies - deliberately configure app server > to stop it using cookies for tracking sessionIDs This does mean that sessions don't survive the user reloading the page or closing his browser. This is generally speaking not acceptable to most GWT developers. My point was: They are in the cookie -anyway-, so worrying about the session ID hitting the wire, while fruitful and of some concern, is outside of the norm. 99% of all websites take this risk. The Sheep Routine (be like everybody else) is *NOT* in general a wise path to take in regards to security, but unless there are a non- trivial amount of non-insane security gurus preaching doom and gloom, you should be okay. In this case, I'm saying that sharing session IDs is generally okay, and I'm not aware of any security gurus preaching doom and gloom. So, session IDs hitting the wire is no (practically solvable) problem. If you have a very sensitive app, you should obviously use SSL, and you may want to invalidate them once in a while. Many sites do this (google invalidates biweekly (fair enough), paypal invalidates every time you breathe to the general annoyance of all, ebay every 24h (similarly ridiculous), et cetera). General Rule: Security does not trump user friendliness. Don't invalidate sessions unless you have a pressing reason to do so. If a tiny, rarely used part of your app is sensitive but the rest isn't, use time-sensitive servlets: Give servlets the time since the session was created and allow a servlet to say that this is no good, which should lead to a login screen. > b) Don't send sessionID as request parameters - or am I wrong here DO send sessionID as parameters. ALWAYS do this. The cookie is there ONLY for the benefit of the client GWT code so that it can fish the sessionID out of the cookie in order to survive reloads and browser quits. If we could tell the browser to stop sending the cookie along, we would. In practice you shouldn't do this (you CAN take down the cookie and add a window closing hook to put it back, but the window closing hook is more of a prayer / hopeful suggestion than something that gets reliably called). You could more reasonably take out the cookie right before you send a request and put it back right after if you're sufficiently paranoid, but there's no serious benefit here unless you also go for the other outside-of-the-norm maneuvre of cryptographically hiding the session ID. So, let me make this perfectly clear: Attempting to keep the session ID out of the hands of people listening on the line is technically possible but something you SHOULD NOT DO unless you are a security expert and/or in the mood to tinker and experiment. It's not something anybody really does right now, though being the first is nice. If you are a tinkerer / experimenter / guru. Not if you're just trying to get on with your project. The reason you, as a server, look ONLY at the session ID transfered in the BODY of the incoming request (instead of the cookie, which would also be there), is to avoid XSRF (a.k.a. seasurf a.k.a. Cross Site Request Forgery, see wikipedia) attacks. In order to properly protect against XSRF, you should also NOT use x-www-form-encoded as your wire format. Use JSON (add session ID as a key/value pair in the top-level map), GWT-RPC (Add it as a field in the class you are passing along the wire), or some non-x-www-form-encoded-fakable format of your own devices, if you have very weird requirements or some such. Don't use XML, obviously - as wire format it's ridiculous. It would be good if you are consistent with this mechanism (for JSON, always call it 'sessionID' and always transfer dictionaries, not arrays, and for GWT-RPC, make everything extend something simple that contains just a getSessionId() method). This way, you can write one generic session ID checker that passes the session ID onwards to your server framework's session system. That's a lot better than forcing every individual servlet to manually fish out the session ID and chat to the session system. It helps ensure that you don't forget to use this alternative session mechanism if you can somehow tell your framework's session system to not mess with cookies (neither write nor read them). Instead, your login servlet will manually generate one (e.g. HttpSession.newSession), send it along to your GWT code, and then your GWT code uses the GWT Cookie class to set the cookie. Similarly, it will retrieve the cookie via GWT's Cookies class, and send that right away to the server if its there (in its entrypoint). This comes back to the reason you're using the cookie in the first place: To let the session survive browser shutdowns and reloads. It's not a reliable authentication mechanism due to XSRF. > c) You could send sessionID as part of a, say, RPC payload object, but > it should be hashed or otherwise encrypted otherwise it's still easily > read by
Re: SecureRemoteService and Servlet. The battle against XSRF.
Sorry Reiner, I wasn't being trying to be facetious. I just wanted to understand exactly what you are saying really. As I understand it so far: a) Don't send sessionID as cookies - deliberately configure app server to stop it using cookies for tracking sessionIDs b) Don't send sessionID as request parameters - or am I wrong here (you say "instead lifting the session out of the parameters)? c) You could send sessionID as part of a, say, RPC payload object, but it should be hashed or otherwise encrypted otherwise it's still easily read by a determined black hat. However, nobody actually does this. In any case encryption libraries available for java script are not Mallory proof) d) The only bomb proof way to serious security (i.e. Mallory proof) is via SSL. I suppose my question is this really: Say you do not want to use SSL (apart from maybe initial log in), but you also don't really want to send session ID's that any old Eve (using your Mallory & Eve thing) can read falling off a log, it's not really clear to me what to if you don't do something like c). Reading your posts back in October last year: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/59f3aafcf4951523 my understanding is: 1) Unless you use SSL across the board you cannot defend against Mallory. However Mallory is rare. 2) Invest $60 in a SSL certificate and run your log-in/lost p/w stuff through SSL otherwise a determined Eve can get uid/pw and simply use the front door 3) To defend against Eve discovering the session, you need a procedure like the one you describe (e.g. key = sessionID + " " + counter + " " + SHA256_HASH(sessionBase,counter++); 4) from Eve's point of view, it doesn't really matter where (key = sessionID + " " + counter + " " + SHA256_HASH(sessionBase,counter++) is in the packet (request parameter, buried in RPC payload whatever) she will find it and either she can crack it or she can't. Therefore your point is (I think, and I appreciate you've been trying to explain this for months until you are blue in the face) there is no point at all in doing something like I was suggesting above for the simple reason that a) if the encryption of the session id is strong enough to defeat Eve, it doesn't matter where it goes in the packet, and b) if it isn't strong enough to defeat Eve, it equally doesn't matter where it goes in the packet. Forgive me if I'm being dense, Reinier, and my applogies if my previous comment offended you, it wasn't meant to. regards gregor On Nov 29, 11:29 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > You're asking me if some Reinier Approved algorithm would meet with my > approval? > > Uh, yes. > > I have a question for you, though: > > Does a gregor approved method of shooting a puppy meet with your > approval? If not, can you explain why? > > On Nov 28, 9:02 pm, gregor <[EMAIL PROTECTED]> wrote: > > > @Reinier > > > > gregor: What do you mean 'bad idea because the session ID would be > > > visible on the wire'? All session IDs are visible on the wire, unless > > > you set up a scheme where the client javascript does some hashing or > > > encryption. > > > Suppose I replaced: > > > sessionID = someSessionIDCookieGrabbingMethod(); > > > with: > > > sessionID = someReinierApprovedEncryptionAlgorithm(); > > > would this meet with your approval? If not can you explain why? > > > regards > > gregor > > > It's been floated as an idea many times on this forum, and > > > > it is certainly feasible, but its very much outside of the norm. > > > Virtually nobody on the entire web is doing this today. There are a > > > number of issues I don't really want to get into. Suffice to say: Yes, > > > doable. Yes, very cool. No, not standard or required by any stretch of > > > the imagination. Such a scheme would still be significantly less > > > secure than SSL, because it won't hold up to a man in the middle > > > attack (the man in the middle will just modify your GWT code to send > > > the password to his secret server in nigerussomania. > > > > On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > > > > > Hey everyone, > > > > > I have been working a while now on properly defending my GWT app > > > > against Cross Site Request Forgery (XRSF) with a minimal change in the > > > > code of the application itself. > > > > > My idea has been to create a new RPC call that will be the same from > > > > the programmers points of view as the normal, but which will add some > > > > value (a sessionID for instance) to the list of supplied parameters > > > > just before the call is send. Then, on the server side, the programmer > > > > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > > > > normal one. This secure version will simply remove the extra > > > > paramater, check it's validity and only execute the requested method > > > > if the authentication succeeds. > > > > > So far I have been able to subclass the RemoteServiceServlet (RSS) > > > > into the SRSS. It
Re: SecureRemoteService and Servlet. The battle against XSRF.
You're asking me if some Reinier Approved algorithm would meet with my approval? Uh, yes. I have a question for you, though: Does a gregor approved method of shooting a puppy meet with your approval? If not, can you explain why? On Nov 28, 9:02 pm, gregor <[EMAIL PROTECTED]> wrote: > @Reinier > > > gregor: What do you mean 'bad idea because the session ID would be > > visible on the wire'? All session IDs are visible on the wire, unless > > you set up a scheme where the client javascript does some hashing or > > encryption. > > Suppose I replaced: > > sessionID = someSessionIDCookieGrabbingMethod(); > > with: > > sessionID = someReinierApprovedEncryptionAlgorithm(); > > would this meet with your approval? If not can you explain why? > > regards > gregor > > It's been floated as an idea many times on this forum, and > > > it is certainly feasible, but its very much outside of the norm. > > Virtually nobody on the entire web is doing this today. There are a > > number of issues I don't really want to get into. Suffice to say: Yes, > > doable. Yes, very cool. No, not standard or required by any stretch of > > the imagination. Such a scheme would still be significantly less > > secure than SSL, because it won't hold up to a man in the middle > > attack (the man in the middle will just modify your GWT code to send > > the password to his secret server in nigerussomania. > > > On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > > > > Hey everyone, > > > > I have been working a while now on properly defending my GWT app > > > against Cross Site Request Forgery (XRSF) with a minimal change in the > > > code of the application itself. > > > > My idea has been to create a new RPC call that will be the same from > > > the programmers points of view as the normal, but which will add some > > > value (a sessionID for instance) to the list of supplied parameters > > > just before the call is send. Then, on the server side, the programmer > > > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > > > normal one. This secure version will simply remove the extra > > > paramater, check it's validity and only execute the requested method > > > if the authentication succeeds. > > > > So far I have been able to subclass the RemoteServiceServlet (RSS) > > > into the SRSS. It overrides the processCall(String payload) method to > > > implement the verification (in my case the last argument, but that can > > > easily be changed), thus working exactly the same as the normal RSS > > > without any change needed in the code other than changing the extend. > > > > The problem is that I really do not understand where I might add the > > > code to modify the sending of the request client side. I have studied > > > the RPC diagrams and almost everything I could find on the group > > > concerning RPC, but I still do not understand what I need to change or > > > override to create a custom RPC call. I have thought about making a > > > subclass of the ServiceDefTarget so that the calling URL could be > > > modified, but this is an interface and not a class, so is not going to > > > work. > > > > Does anyone have any idea's on this? > > > > Patrick > > > > PS: If I succeed at making something useful, I will create a package > > > and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
@Reinier > gregor: What do you mean 'bad idea because the session ID would be > visible on the wire'? All session IDs are visible on the wire, unless > you set up a scheme where the client javascript does some hashing or > encryption. Suppose I replaced: sessionID = someSessionIDCookieGrabbingMethod(); with: sessionID = someReinierApprovedEncryptionAlgorithm(); would this meet with your approval? If not can you explain why? regards gregor It's been floated as an idea many times on this forum, and > it is certainly feasible, but its very much outside of the norm. > Virtually nobody on the entire web is doing this today. There are a > number of issues I don't really want to get into. Suffice to say: Yes, > doable. Yes, very cool. No, not standard or required by any stretch of > the imagination. Such a scheme would still be significantly less > secure than SSL, because it won't hold up to a man in the middle > attack (the man in the middle will just modify your GWT code to send > the password to his secret server in nigerussomania. > > On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > > > Hey everyone, > > > I have been working a while now on properly defending my GWT app > > against Cross Site Request Forgery (XRSF) with a minimal change in the > > code of the application itself. > > > My idea has been to create a new RPC call that will be the same from > > the programmers points of view as the normal, but which will add some > > value (a sessionID for instance) to the list of supplied parameters > > just before the call is send. Then, on the server side, the programmer > > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > > normal one. This secure version will simply remove the extra > > paramater, check it's validity and only execute the requested method > > if the authentication succeeds. > > > So far I have been able to subclass the RemoteServiceServlet (RSS) > > into the SRSS. It overrides the processCall(String payload) method to > > implement the verification (in my case the last argument, but that can > > easily be changed), thus working exactly the same as the normal RSS > > without any change needed in the code other than changing the extend. > > > The problem is that I really do not understand where I might add the > > code to modify the sending of the request client side. I have studied > > the RPC diagrams and almost everything I could find on the group > > concerning RPC, but I still do not understand what I need to change or > > override to create a custom RPC call. I have thought about making a > > subclass of the ServiceDefTarget so that the calling URL could be > > modified, but this is an interface and not a class, so is not going to > > work. > > > Does anyone have any idea's on this? > > > Patrick > > > PS: If I succeed at making something useful, I will create a package > > and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
The solution is simple: Rewrite the session management part of your web stack so that it doesn't look at the cookie (it should completely ignore the cookie - it is there only to let the session survive when the user reloads the page / closes their browser), instead lifting the session out of the parameters. You don't need to remove it, really - any framework or servlet engine that gives unfettered access to the parameters also gives unfettered access to the cookies, so there's no point. gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband <[EMAIL PROTECTED]> wrote: > Hey everyone, > > I have been working a while now on properly defending my GWT app > against Cross Site Request Forgery (XRSF) with a minimal change in the > code of the application itself. > > My idea has been to create a new RPC call that will be the same from > the programmers points of view as the normal, but which will add some > value (a sessionID for instance) to the list of supplied parameters > just before the call is send. Then, on the server side, the programmer > would extend the SecureRemoteServiceSevlet (SRSS) instead of the > normal one. This secure version will simply remove the extra > paramater, check it's validity and only execute the requested method > if the authentication succeeds. > > So far I have been able to subclass the RemoteServiceServlet (RSS) > into the SRSS. It overrides the processCall(String payload) method to > implement the verification (in my case the last argument, but that can > easily be changed), thus working exactly the same as the normal RSS > without any change needed in the code other than changing the extend. > > The problem is that I really do not understand where I might add the > code to modify the sending of the request client side. I have studied > the RPC diagrams and almost everything I could find on the group > concerning RPC, but I still do not understand what I need to change or > override to create a custom RPC call. I have thought about making a > subclass of the ServiceDefTarget so that the calling URL could be > modified, but this is an interface and not a class, so is not going to > work. > > Does anyone have any idea's on this? > > Patrick > > PS: If I succeed at making something useful, I will create a package > and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
On Fri, Nov 28, 2008 at 03:52, Patrick Ratelband <[EMAIL PROTECTED]>wrote: > > I have been working a while now on properly defending my GWT app > against Cross Site Request Forgery (XRSF) with a minimal change in the > code of the application itself. I've done something similar for an application I am working on, but the RPC format uses pure JSON rather than the GWT RPC system. For the most part it serializes just about anything GWT RPC would serialize, but the object property names appear "plain text" on the wire. The advantage of course is non-GWT clients and servers can actually speak to each other. Standard JSON along with automatic XSRF were my main requirements. The application I am using it in is open source, I don't want to be obfuscating the wire protocol. The RemoteJsonServlet base class automatically handles XSRF key generation and validation, so you extend it and implement your interface. The client side proxies are generated to automatically insert the XSRF token into the HTTP request headers. So its fairly transparent to the application. Its still under development, but I'm using it in Gerrit 2, and thus far its working out quite nicely for my needs. Code is here: http://android.git.kernel.org/?p=tools/gwtjsonrpc.git;a=summary README describing it in a bit more detail: http://android.git.kernel.org/?p=tools/gwtjsonrpc.git;a=blob;f=README;hb=HEAD --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Hi Patrick,
You could add parameters to the URL from an inner class inside the
RemoteService interface e.g.
public interface MyService extends RemoteService {
MyReturnValue aMethod();
/**
* Utility/Convinience class.
* Use MyService .App.getInstance() to access static instance of
IpsvRmapServiceAsync
*/
public static class App {
private static MyServiceAsync ourInstance = null;
public static synchronized MyServiceAsync getInstance() {
if (ourInstance == null) {
ourInstance = (MyServiceAsync ) GWT.create
(MyService.class);
// alter the URL here
((ServiceDefTarget) ourInstance).setServiceEntryPoint
(GWT.getModuleBaseURL() + "MyService");
}
return ourInstance;
}
}
However that is probably not such a good idea 'cos the session ID
would be visible on the wire.
A second ideas is to use a variation of the Command pattern which
might better be called Payload since it doesn't execute() anything
itself on arrival. Something like
public abstract class Payload implements Serializable {
private String sessionID;
public Payload() {
sessionID = someSessionIDCookieGrabbingMethod();
}
// or alternatively
public Payload(String sessionID) {
this.sessionID = sessionID;
}
public String getSessionID {
return sessionID;
}
}
Then if you then extend this to make individual RPC service parameters
(a sort of "bucket" for the objects you need to pass over for each
service call (although sometimes they are reusable for several calls)
you can cast them all to Payload in your override processCall and
examine and validate the sessionID before processing the call.
regards
gregor
On Nov 28, 11:52 am, Patrick Ratelband <[EMAIL PROTECTED]> wrote:
> Hey everyone,
>
> I have been working a while now on properly defending my GWT app
> against Cross Site Request Forgery (XRSF) with a minimal change in the
> code of the application itself.
>
> My idea has been to create a new RPC call that will be the same from
> the programmers points of view as the normal, but which will add some
> value (a sessionID for instance) to the list of supplied parameters
> just before the call is send. Then, on the server side, the programmer
> would extend the SecureRemoteServiceSevlet (SRSS) instead of the
> normal one. This secure version will simply remove the extra
> paramater, check it's validity and only execute the requested method
> if the authentication succeeds.
>
> So far I have been able to subclass the RemoteServiceServlet (RSS)
> into the SRSS. It overrides the processCall(String payload) method to
> implement the verification (in my case the last argument, but that can
> easily be changed), thus working exactly the same as the normal RSS
> without any change needed in the code other than changing the extend.
>
> The problem is that I really do not understand where I might add the
> code to modify the sending of the request client side. I have studied
> the RPC diagrams and almost everything I could find on the group
> concerning RPC, but I still do not understand what I need to change or
> override to create a custom RPC call. I have thought about making a
> subclass of the ServiceDefTarget so that the calling URL could be
> modified, but this is an interface and not a class, so is not going to
> work.
>
> Does anyone have any idea's on this?
>
> Patrick
>
> PS: If I succeed at making something useful, I will create a package
> and a tutorial to share my knowledge. No need to reinvent the wheel.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
SecureRemoteService and Servlet. The battle against XSRF.
Hey everyone, I have been working a while now on properly defending my GWT app against Cross Site Request Forgery (XRSF) with a minimal change in the code of the application itself. My idea has been to create a new RPC call that will be the same from the programmers points of view as the normal, but which will add some value (a sessionID for instance) to the list of supplied parameters just before the call is send. Then, on the server side, the programmer would extend the SecureRemoteServiceSevlet (SRSS) instead of the normal one. This secure version will simply remove the extra paramater, check it's validity and only execute the requested method if the authentication succeeds. So far I have been able to subclass the RemoteServiceServlet (RSS) into the SRSS. It overrides the processCall(String payload) method to implement the verification (in my case the last argument, but that can easily be changed), thus working exactly the same as the normal RSS without any change needed in the code other than changing the extend. The problem is that I really do not understand where I might add the code to modify the sending of the request client side. I have studied the RPC diagrams and almost everything I could find on the group concerning RPC, but I still do not understand what I need to change or override to create a custom RPC call. I have thought about making a subclass of the ServiceDefTarget so that the calling URL could be modified, but this is an interface and not a class, so is not going to work. Does anyone have any idea's on this? Patrick PS: If I succeed at making something useful, I will create a package and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
