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 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
