On Jul 3, 2014, at 00:43 , Torsten Irländer <[email protected]> wrote:
> > > Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius: > Am 02.07.2014 23:01, schrieb Torsten Irländer: >> >> >> Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer: >> >> On Jul 2, 2014, at 7:29, Torsten Irländer <[email protected]> wrote: >> > I guess that most people only talk about protecting post request since they > _think_ that the web application would be programmed this way, that all > actions (like deleting all contacts) would only be accessable via a POST > request. So they THINK there is no need in protecting GET requests. But I > know web applications that also change data via GET requests. > > Buttriggering a GET request that only _reads_ your addresses, would display > the addresses and not change them. (Well, Maybe some code can also steal the > addresses) > > That's the point. If those addresses are not public and considered to be only > visible to authenticated users, than such a GET request is a large security > issue ( if such a request is realistic at all ) > > > Nevertheless I absolutely recommend to also protect GET requests against CSRF! > > Ok, and how would you do it in pyramid? > > Torsten With the current cross domain policies that browsers have, how is an attacker going to read the data when they issue a GET request? There is no way for an attacker to currently read data from an external site unless you go out of your way to make it possible (such as CORS/JSONP). If an attacker IS ABLE to somehow read content from your website by having someone issue a GET request, they can also an issue an GET request for http://example.com/, which will include links in the HTML to those pages that would include the CSRF token: http://example.com/ links to http://example.com/some/super/duper/secret/address?csrf_token=79dDe4F627882c9E So if this is an actual thread model, you can’t provide any links at all from your main page when a user is logged in, unless they manually concatenate the csrf_token to the URL (but where are they getting it at that point?) There is no reason to add a CSRF token to GET requests. POST, yes, DELETE, no, PUT, no, OPTIONS, no, GET, no, HEAD, no, TRACE, no. POST is the only HTTP verb that can be sent from current browsers with abandon, there are no restrictions from either JavaScript or from within a page itself. You can POST all over the world. The way to stop that is to add a CSRF token to your forms so only forms your server has generated are actually acted upon when receiving a POST. Bert JW Regeer
smime.p7s
Description: S/MIME cryptographic signature
