Fixing CSRF exploits in Infrastructure

[Chuck Anderson]

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/