Fixing CSRF exploits in Infrastructure

[Toshio Kuratomi]

Till Maas wrote:
> On Wed November 26 2008, Toshio Kuratomi wrote:
> 
>> To be easy to code, require the token for every request of an
>> authenticated user.
> 
> If I understand your proposal correctly, a user would need to login again for 
> every link he clicks from his bookmarks or any mail he gets from a Fedora 
> webapplication, e.g. packagedb.

You are correct.  This is mentioned in a different way in the "Other
Notes" section:

"We can make all links between Fedora Services carry the special session
information. That will allow a link from the pkgdb to bodhi to stay
logged in, for example, but it will not allow a user to open up a second
tab and be logged in there. So this destroys some of the single-sign-on
ability that we have now."

I've now updated this to be clearer that this affects bookmarks and
links in messages sent by the system.

If the proposal was to manually mark which methods make changes and only
those, then we'd be able to do this instead:  User can bookmark links to
pages which present choices to users (like a form).  The form will be
submitted with the double submit method using the values of the current
cookie.

The con of this is that the consequences of not marking a method are a
security hole this way.  One that we would have to audit the code to
discover.  I'm not a big fan of this tradeoff but I'm open to comments
-- is this something that's so big a regression that we should bite the
bullet and do it?  Can we come up with another method that protects the
users from failure by the programs author to properly mark the methods?

> And with every login a previous session is 
> invalidated, which also includes links in another open browser tab, where the 
> user logged after he clicked the previous link.
> 
So this is interesting.  This is true since we wanted to remove the need
to hash the tg-visit in javascript and thus the token is 100% statically
derived.  We could work around this in several ways:

1) In addition to checking the hash against the tg-visit, check against
any non-expired session.  If we did this check in the FAS server (all
authentication goes back to the FAS server already) then I think that
would work.  So we'd send the FAS server the tg-visit cookie and the
token.  Then the FAS server would do the comparison of the token to the
visit cookie; comparison to the visit to the current active sessions,
and finally, if the token did not match the cookie, between the token
and other non-expired sessions owned by the user.

This seems like a relatively simple change to the proposal (change the
server in one place to do a transparent check for the rest of the code).
 The only question would be how easy it is to send the token to the FAS
server via the TurboGears identity methods... from a brief refresher
look at jsonfas I think this is doable but it would be the hardest part.

2) Change to have javascript hash the cookie dynamically.  This brings
in two dependencies: javascript and a hashing library.  The cookie
that's sent to the web site will be updated when the user logs in on the
second tab.  If we then switch back to the first tab and the javascript
there reads the cookie value and hashes it, we will have a valid token
when that's submitted.  In case javascript is turned off we'd still need
to include the cookie information statically, this just would be
replaced in normal circumstances.

I've added #1 to the proposal for now.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20081125/279d4573/attachment.sig>