incubator-shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graeme Rocher" <gra...@g2one.com>
Subject Re: JSecurity and CSRF
Date Wed, 01 Oct 2008 22:18:52 GMT
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 <les@hazlewood.com> 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 <graeme@g2one.com> 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 <les@hazlewood.com> 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 <graeme@g2one.com> 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 <les@hazlewood.com> 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 <graeme@g2one.com>
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 <les@hazlewood.com>
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 <peter@g2one.com>
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

Mime
View raw message