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::
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
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"
/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
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.