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/ _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
