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.