Fixing CSRF exploits in Infrastructure

[Toshio Kuratomi]

Chuck Anderson wrote:
> On Wed, Nov 26, 2008 at 04:53:00PM +0100, Till Maas wrote:
>> How big the regression is if users have to log in for every external link they 
>> click on, depends on how often this happens. I believe that links to FAS are 
>> not exchanged very often, therefore it will not hurt very much. I guess there 
>> is also not so often a need to use FAS with tabs. But maybe there are people 
>> who have to use FAS more often. With Bodhi it is contrary, because there it 
>> is normal to get mails with links if someone added a comment to a package or 
>> for testers to exchange links to Bodhi updates. Also links to Bodhi updates 
>> are used in Bugzilla comments. There it would have a much bigger impact on 
>> the efficiency of testing new package updates imho.
>>
>> Regarding the time needed for auditing applications: There may still be a lot 
>> of other vulnerabilites in these applications which cannot be fixed 
>> automatically. Therefore they still need to be written carefully. But maybe a 
>> compromise would be to require the token for all requests by default and then 
>> whitelist the ones, that are not meant to change state, e.g. requests like:
>>
>> https://admin.fedoraproject.org/updates/pstreams-devel-0.6.0-6.fc10
>>
>> Nevertheless it seems to me that securing all requests against CSRF 
>> automatically makes it a little easier to write a application, because the 
>> author does not need to care whether a request changes state or not. On the 
>> downside it has a high impact on usability or makes the automatic CSRF 
>> protection a lot more complicated. Also securing all requests may cost a lot 
>> of performance, because more requests need to be made.
>> Last but not least is always more time spent on using an application than on 
>> writing it, therefore if the usability of an application is only enhanced a 
>> little, because of the many times it is used, there will be more manpower 
>> saved than is used to enhance the application.
> 
> Has anyone taken a look at PubCookie?  It sounds like we are trying to 
> re-invent the wheel here, which is probably not a good idea when it 
> comes to security-related infrastructure.
> 
> http://www.pubcookie.org/
> 
It doesn't seem to have a way of protecting the apps from CSRF so it
doesn't appear to apply directly to this situation.  A very quick look
at the docs seems like it's better than what we have now in that it
redirects you to the actual login server for authentication instead of
taking authentication on the web app and then proxying to the login
server.  However, it also is not flexible enough for our usage in and of
itself because it only deals with authentication, not authorization.  So
we'd have to do quite a bit of work to integrate this.

We've been wanting to implement SSL Certificate auth which would get us
away from the need for something like pubcookie in some respects as
well.  But there's two big barriers: 1) SSL Cert, like pub cookie is
only for authentication, not authorization, 2) It looks like there's
going to be some issues to work with between CSRF and SSL Certs.

-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/20081126/c88e31ab/attachment.sig>