Hi Les, Yeh I personally think it would make sense to add the functionality to the default Filter. There should also be some configuration option so you can enable/disable the feature.
We can then work on integrating the tag it into the JSecurity plugin on the Grails side Cheers On Wed, Oct 1, 2008 at 11:13 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > Yep, just read that. If that is the case, this is an incredibly easy > fix for non-ajax situations: > > 1. Create a <jsec:sessionId/> tag that prints out a hidden field: > <input type="hidden" name="JSESSIONID" > value="runtime_session_id_value"/> > 2. Create a Filter implementation that checks the following: > > Is there a 'JSESSIONID' parameter in the current request? > - Yes: does it match a previously set Cookie named JSESSIONID? > - Yes: request is valid, let it through > - No: potential CSRF attack, show access denied view > - No: no JSESSIOND parameter - let the request through as normal. > > 3. Add this to the jsecurity [urls] definition: > /** = antiCsrf > > JSecurity doesn't have any AJAX support at all since that varies > dramatically across web environments, so I'm not sure it could do the > AJAX double submit technique. I do know a JS guru that could help me > find a way if its possible... > > Whaddya think? Does this sound like a viable solution moving forward? > > Actually, I wonder if this should logic should be included in the raw > functionality of JSecurity's sessionId acquisition logic when deployed > in web apps - not a user configurable Filter (in case they forget to > configure that filter in the [urls] definition. > > P.S. This needs to be archived, so I'm cc'ing the JSec Dev list... > > On Wed, Oct 1, 2008 at 5:17 PM, Graeme Rocher <[EMAIL PROTECTED]> wrote: >> Apparently just sending the session cookie in a hidden field and >> comparing the values on the server is a valid fix. At least that is >> how they seem to have implemented it in DWR. See >> >> http://directwebremoting.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html >> >> Cheers >> >> On Wed, Oct 1, 2008 at 9:01 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>> I'll look into the presentation - thanks! >>> >>> But I don't see how a timestamp would matter much. For example, if >>> site B did the redirect back to site A (using your previous example), >>> that would usually be done within the user's session - often at the >>> same time (or within milliseconds or seconds) of the initial rendering >>> of site A's first page. >>> >>> My other question is when/where would the token be generated? >>> Obviously for it to be verified on a subsequent request, it first >>> needs to be 'bound' somewhere to retrieve for the next request. >>> >>> For example, using <c:out>, it uses response.encodeUrl, which does >>> this work. Where/how would an end-user do this? Maybe a sample >>> workflow would help if you could throw one together... >>> >>> Sorry - I'm just trying to lessen my disconnect! >>> >>> Thanks, >>> >>> Les >>> >>> On Wed, Oct 1, 2008 at 3:23 PM, Graeme Rocher <[EMAIL PROTECTED]> wrote: >>>> The token needs to be made up of the session id and some time-based >>>> value to avoid replay attacks as you said. So maybe if you take a >>>> random number + session id + the current time in millis then create a >>>> blowfish encrypted token. Something like >>>> >>>> encrypt("43243-${session.id}-${System.currentTimeMillis()}") >>>> >>>> Then on the server you decrypt the value discard the random number, >>>> read the session id, check that the time value is within the valid >>>> time period (last 15 minutes?) and if not send the request back as not >>>> authorized >>>> >>>> Apparently yahoo use a "crumb" for this. See >>>> http://www.slideshare.net/simon/when-ajax-attacks-web-application-security-fundamentals-presentation/ >>>> >>>> Which seems a good presentation on the subject >>>> >>>> Thoughts? >>>> >>>> On Wed, Oct 1, 2008 at 7:16 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>>>> Appending the session id to the url poses its own separate problems >>>>> (session >>>>> fixation attacks, referrer logging attacks, users emailing links to other >>>>> users, etc), and requires that the website programmer (or toolkit) call >>>>> response.encodeUrl(...) (e.g. jstl's <c:out> tag). I'm assuming this >>>>> would >>>>> be OK? I mean, this would happen anyway if cookies were disabled, so >>>>> there's no alternative in that case really. >>>>> >>>>> But the token idea is interesting - how would the token be validated? If >>>>> it >>>>> is the session id, that's obviously easy. But given the above other >>>>> exploits, maybe it should be some other ID? perhaps a UUID generated just >>>>> for that request? But then how would the website programmer ensure it is >>>>> used properly? >>>>> >>>>> Just looking for ideas, suggestions... >>>>> >>>>> On Wed, Oct 1, 2008 at 11:58 AM, Graeme Rocher <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Hi Les, >>>>>> >>>>>> CSRF doesn't rely on the session id or user cookie. Essentially say >>>>>> you're logged into site X using jsecurity. You're a logged in valid >>>>>> user at this point. You then browse to another site B, this site B is >>>>>> evil and has a malicious form that sends the request back to site X to >>>>>> perform some site function (maybe updating data, reseting passwords >>>>>> whatever). Because you are logged in and you have a valid cookie it is >>>>>> allowed by the browser >>>>>> >>>>>> The only way to protect against such an attack is to have some kind of >>>>>> id attached to every request that modifies the data of the server. The >>>>>> id needs to be unique (hence the session id). It would be nice if >>>>>> JSecurity provided built in CSRF capability somehow. Maybe in each >>>>>> form like this you could have a >>>>>> >>>>>> <form action="/modify/some/data"> >>>>>> <jsecurity:token /> >>>>>> </form> >>>>>> >>>>>> Then Jsecurity would validate the token. If then evil site B tried to >>>>>> use CSRF to send a request "/modify/some/data" then a 401 would be >>>>>> returned since the token is not sent by evil site B >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Cheers >>>>>> >>>>>> On Wed, Oct 1, 2008 at 4:45 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>>>>> > JSecurity sets the cookie relative to the application path by default, >>>>>> > which >>>>>> > itself is bound by a domain. I _thought_ cookies from one domain are >>>>>> > not >>>>>> > sent to cookies from another domain by the browser. >>>>>> > >>>>>> > So, in CSRF, if you're visiting a forum on myforum.com and have a >>>>>> > cookie, >>>>>> > JSESSIONID or rememberMe, it is bound to myforum.com. >>>>>> > >>>>>> > If there is a CSRF attack, say, someone posts in that forum, <img >>>>>> > src="http://othersite.com/images/sneakyimage.jpg?blah=blah"/>, I'm >>>>>> > assuming >>>>>> > that lookup results in an HTTP request to a different domain, where the >>>>>> > cookies for only that domain are sent. >>>>>> > >>>>>> > If this is _not_ the case - i.e. the cookies for the domain currently >>>>>> > in >>>>>> > the >>>>>> > browser address bar are sent with all HTTP requests for the current >>>>>> > page, >>>>>> > then no, JSecurity doesn't provide any such prevention - it relies on >>>>>> > the >>>>>> > browser to do the right thing and make cookies only accessible to the >>>>>> > domains that set them in the first place. >>>>>> > >>>>>> > I suppose in the above example if the image request results in >>>>>> > JavaScript, >>>>>> > not an actual image, there could be a problem with that script then >>>>>> > reading >>>>>> > the cookies off of the browser locally. >>>>>> > >>>>>> > Do you guys know the current browser behavior? >>>>>> > >>>>>> > I also don't know that an md5 would work - you'd have to do something >>>>>> > like >>>>>> > this: >>>>>> > >>>>>> > Md5Hash(currentDomainName + sessionId) = cookie value >>>>>> > >>>>>> > But, the session id itself needs to be deciphered on the next request >>>>>> > to >>>>>> > actually look up the session. Since MD5 is one way, you can't do this. >>>>>> > You'd have to essentially do a 2 way encryption, like using Blowfish >>>>>> > (which >>>>>> > is what we do for the rememberMe cookie). >>>>>> > >>>>>> > If you guys have any ideas (or you think adding the domain to the >>>>>> > cookie >>>>>> > value and then using 2-way encryption is the best way), then lemme >>>>>> > know, >>>>>> > and >>>>>> > I'll add it ASAP. >>>>>> > >>>>>> > Cheers, >>>>>> > >>>>>> > Les >>>>>> > >>>>>> > >>>>>> > On Wed, Oct 1, 2008 at 8:06 AM, Peter Ledbrook <[EMAIL PROTECTED]> >>>>>> > wrote: >>>>>> >> >>>>>> >> > Does JSecurity implement anything for CSRF? For example using an md5 >>>>>> >> > of the session id to ensure incoming requests are only from your >>>>>> >> > site? >>>>>> >> >>>>>> >> I don't know, so I've cc'ed Les in. Les, is there anything that you >>>>>> >> know >>>>>> >> of? >>>>>> >> >>>>>> >> Cheers, >>>>>> >> >>>>>> >> Peter >>>>>> >> >>>>>> >> -- >>>>>> >> Software Engineer >>>>>> >> G2One, Inc. >>>>>> >> http://www.g2one.com/ >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Graeme Rocher >>>>>> Grails Project Lead >>>>>> G2One, Inc. Chief Technology Officer >>>>>> http://www.g2one.com >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Graeme Rocher >>>> Grails Project Lead >>>> G2One, Inc. Chief Technology Officer >>>> http://www.g2one.com >>>> >>> >> >> >> >> -- >> Graeme Rocher >> Grails Project Lead >> G2One, Inc. Chief Technology Officer >> http://www.g2one.com >> > -- Graeme Rocher Grails Project Lead G2One, Inc. Chief Technology Officer http://www.g2one.com
![http://othersite.com/images/sneakyimage.jpg?blah=blah"/](http://othersite.com/images/sneakyimage.jpg?blah=blah"/){kind=link}