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
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.
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,
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
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.
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)
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
@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 =
21 matches
Mail list logo
