Till Maas wrote: > On Mon November 24 2008, Toshio Kuratomi wrote: > >> I've been researching the CSRF exploit and how it affects our web apps >> recently. The short story is that our code is pretty open to this at >> the moment. I've written up a proposal for fixing this but it will >> require a lot of coding so I'd love to have some more eyes on it to make >> sure I'm not making any stupid mistakes. >> >> The proposal is here:: >> https://fedorahosted.org/fas/wiki/CSRF > > From the proposal: > | make a GET request that can change state on the server > > It is recommended to not use GET requests to change state on the server, > therefore it would be probably better to change these GET requests to POST > requests. > The proposal doesn't specifically mention POST there as well but it should to make things clearer: "Every time we submit a form or make a GET request that can change state on the server" s/submit/POST/ /me changes that now. The reasons the proposal is explicit about GET are: 1) We'd have to constantly audit code for places where GET is being used to alter state and change that. This is doable if the app authors are aware of this but not so scalable if it's me going through and making those changes. 2) It is hard in most web frameworks to separate GET and POST requests. The framework takes the request and abstracts whether a GET or POST was used to send the variables and just send the variables themselves into the methods. The methods that receive the calls would have to jump through hoops to tell where the variables came from. So... if the proposal is secure for both POST and GET, I'd rather do that. If you can show where GET cannot be made secure (which is possible, I tried to examine the possibilities there and only came up with logging as a problem area but more eyes on this, the better) then we'll have to add a section for how to separate POST and GET requests in TurboGears and do periodic auditing to make sure methods which aren't marked POST-only aren't allowing changes to be made. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
