Tom Evans wrote:
> 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
>
> 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) ????
In step {n}, the user returns to page X where they can review the
data before submitting it (now as a logged-in user rather than
anonymously). If it's bogusly transferring money to $HACKER's
account, step {p'} would be to bail on the transaction. From my
understanding the CSRF would only occur if step {n-p} didn't
occur, automatically submitting the POST instead.
If you see a bogus money-transfer in {n} and still click to
submit the action, well as the saying goes, "you can't fix
stupid". I mean...the application doesn't prevent you from
typing in a money transaction to $HACKER and submitting it by
hand either.[1]
-tim
[1]
http://www.google.com/search?q=amish+virus
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
