I see your point. If the SID is invalid, either via a real attack or by
session invalidation, the result is the same... "I don't know who you are so
please re-authenticate yourself." My project is in its early stages, so for
what I thought was an attack I was just throwing an exception to kick that
request back to where it came from. I believe I'll just handle it like the
user isn't logged in and send it to the login view. Thanks for your input.
As for the get parameter... in my RemoteService interfaces, where I have the
static getInstance to get the Async instance I essentially pass in the sid
and build the url with that sid.
<pre>
public static synchronized AuthenticationServiceAsync
getInstance(String sid) {
if (ourInstance == null) {
ourInstance = (AuthenticationServiceAsync)
GWT.create(AuthenticationService.class);
}
((ServiceDefTarget) ourInstance)
.setServiceEntryPoint(GWT.getModuleBaseURL() +
"com.vincent.gwtapps.myApp.MyGwtApp/AuthenticationService?sid=" + sid);
return ourInstance;
}
</pre>
On Tue, Nov 4, 2008 at 4:19 AM, walden <[EMAIL PROTECTED]> wrote:
>
> Jason,
>
> I think false positives is a feature of this kind of security
> strategy, not necessarily a bad thing. How do you handle what you
> think is a real "XSRF" attack? When I use Yahoo (not often), it seems
> like it asks me to login a lot. But they smooth the experience with
> words to the effect that it's for a good cause. Since the reality is
> that you can't be sure when a sid error is an attack, why not be
> candid about it?
>
> BTW, how do you use RPC to send a "get parameter"? That part confused
> me.
>
> Walden
>
> On Nov 3, 4:59 pm, Jason <[EMAIL PROTECTED]> wrote:
>> I have a question about the "XSRF" protection. I've implemented this
>> by using a requestFilter which filters for the "nocache.js" file and
>> sets a "sid" cookie with the session id as the value. Then for each
>> RPC call I send the value of the "sid" cookie as a get parameter.
>> When the session is active this works great. The issue I have is when
>> the session expires, or invalid for some reason. Currently this is
>> reporting a false "XSRF" attack since the sid no longer matches the
>> session id on the server.
>>
>> If the sid is based off the session Id (or anything that changes over
>> time), how might it get updated when the session id gets invalidated?
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
