On Fri, 2009-05-15 at 16:10 -0500, Tim Chase wrote:
> James Bennett wrote:
> > On Fri, May 15, 2009 at 1:55 PM, Tim Chase
> > <[email protected]> wrote:
> >> One more option that occurs to me is that you can stash all of
> >> the POSTed variables into a session-store with a hash key,
> >> redirect with some sort of "load POST variables from this
> >> hash-key" GET page, and then when the login is done, redirect to
> >> your form, loading the contents from the session-store based on
> >> the key you pass in.
> >
> > The Django admin used to do this, actually.
> >
> > Then we stopped doing it because it turns out to be a gigantic
> > security hole that can't be closed -- doing this basically consists of
> > building a free CSRF exploit into your site.
>
> I've read up at [1] and it seems that for a one-time transfer, if
> the token was a hash (effectively unguessable), and a successful
> transfer deleted the item from the session-store when complete,
> it removes the problem. Sample session:
>
> a) unauthenticated user requests form/view X
> b) user fills out form
> c) user tries to save/POST, but view X requires a logged-
> in user
> d) view X saves the posted data to a session table
> e) view X builds a signed token/hash with that session ID
> such as sha1("%s%s" % (settings.SECRET_KEY, inserted_id))
> f) view X redirects to login page with a redirect back to X
> including the token in the GET parameters
> g) user arrives at login page with uname/pwd boxes and token
> as a hidden field value
> h) user posts to login page, signing in
> j) login page redirects user to view X, passing the "load
> data from this saved slot" hash
> k) user hits view X which notices the "load data from this
> saved slot" GET parameter and that the user is now
> authenticated, so it loads the data into the form
> m) view X then deletes the data from the session-store[2]
> n) user is now at view/page X with their original data, but
> is now signed in
> p) user can now save/POST a 2nd time, this time as an
> authenticated user
>
> My understanding from [1] is that a successful CSRF requires a
> logged in user to perform the action (which doesn't occur until
> "h"), and then being able to build a known GET url (which
> requires the generated SHA1 token) so the window of opportunity
> for exploit is one redirect worth of time (h-m), and finally
> being able to make the POST directly. The only potential hole I
> see is that an existing authenticated user might theoretically be
> able to guess the token and load somebody else's data to post as
> themselves, but this would require guessing the SHA1 token.
> Additional user-associated information could be required by the
> view to mitigate this, but if attackers knowing your
> SHA1/SECRET_KEY is a concern, you have other problems ;-)
>
> I'm missing where the window of CSRF opportunity lurks. Or maybe
> I made assumptions about the flow that protect against less safe
> workflows. Or perhaps I poorly explained what I envisioned. Am
> I still off-base with this idea, vulnerable to CSRF?
>
> -tim
>
> [1]
> http://en.wikipedia.org/wiki/Csrf
>
> [2]
> at this point, I'd delete that token as well as purge out any
> other tokens older than $TIMEDELTA to keep the session-store from
> growing humongous with unused session data.
>
while true:
1) Evil hacker signs up to your site, and works out what values
you need to submit to your site to transfer money to his
account.
2) Evil hacker logs out, and submits the form to your site,
lifts the token.
3) Your site recognises he needs to login, stores the post data,
and gives him a nice token
4) Evil hacker pops up window on 250,000 machines showing your
site, with your security credentials prompting them to log in,
and submit his crafted data. One person falls for it.
5) ????
PROFIT
:)
Tom
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
