4 ms·

The difference between GET and POST is interface-related, not security-related. A better example for why you avoid GET for non-idempotent operations is to prev

by pak 16y ago

The difference between GET and POST is interface-related, not security-related. A better example for why you avoid GET for non-idempotent operations is to prevent a webcrawler from coming along and innocently making massive changes to your site just by following links. Security-wise, there's little difference between the two, it's trival for the client to change the type of request. (If I can't get some guy on a forum by embedding a picture, I'll send him a link to some website I control where there's a hidden <form> that posts to the site I want.) CSRF is only preventable by putting secret tokens in your forms that get echoed in the submission request (or by double-submitting the cookie as I do, but tptacek will be in here shortly to tell me why that is so silly).

TimothyBurgess 16y ago
Indeed. I actually just finished implementing the secret token method throughout my app less than a minute ago. I have fullscreen and mobile versions... and without going into too much detail on exactly why in my particular case, it's cleaner and easier to use simple links (i.e., GET) for something like removing items from lists... so the token method is the only feasible solution to prevent something like I mentioned in my other comment (fake images and what not). But with the fullscreen version, since it's all AJAX and to make things easy on myself, I converted everything (except file uploads) to send data via POST (all links are generated by a function so instead of href it's onclick+ajax)... along with the token too of course... which was all a win-win because I lifted the data limit that GET used to impose as well. But anyway... today I learned that even though GET and POST are no different security-wise... always use a secret token when security is an issue... and it's best to use POST because it allows MUCH more data than GET.
tzs 16y ago
There is one security difference. POST doesn't leave the data in the URL bar at the top of the browser. I sure would rather a site submit my credit card via POST than via GET.
- marcinw 16y ago
  In addition to tzs' comment above, POST parameters do not get logged by the web server either (default Apache logging, etc), unless you're using a module like mod_security to log POST data. Besides, don't use GET for non-idempotent requests (those which change state). That's just webapp development 101. Edited for clarity.
  - axiak 16y ago
    Either I'm completely misunderstanding your grammar, or you don't understand what idempotent means... idempotent and state-changing are almost opposites.
    - fhars 16y ago
      You don't understand what idempotent means. An action is idempotent if repeating it does not change the result. For example, multiplying by zero is idempotent, 0 * x is the same as 0 * 0 * 0 * 0 * x. But of course it changes something, as 0 * x is clearly not x in the general case. In the http case, GET and HEAD should not change any state (be safe and idempotent), PUT and DELETE should change state but be idempotent, and POST can do whatever it wants. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
      - axiak 16y ago
        Maybe you saw the text after @marcinw changed his text? I agree with you, of course I will say that most http GET actions I see are trivially idempotent -- that is to say they are idempotent because they don't change the state at all.
        fhars 16y ago
        No, I saw the original version that cautioned against state changing idempotent GET requests. The changed version is actually worse, as it only cautions against non-idempotent GETs, which is not enough. State changing idempotent requests via GET are quite as bad. In fact, idempotency is irrelevant for GET, as GET requests should be safe, which trivially implies that they are idempotent. So requiring idempotency in addition to safety does nothing except making the prose harder to read.
KevBurnsJr 16y ago
Your `hidden form` exploit is moot for the example in the post <img src="http://example.com/do.php?action=delete&id=3 http://example.com/do.php?action=delete&id=3 />
tptacek 16y ago
Nope, that's exactly what I came here to say. Thanks! People conflate CSRF-ability with destructive GET operations because a lot of apps that are pervasively CSRF-able also happen to have lots of inadvertant destructive GET's, but the bad GET endpoints are a reliability flaw more than a security flaw.
andrewvc 16y ago
That's true 99.99% of the time. However, just to play devil's advocate, there is a class of attacks based around injecting code into logfiles since they'll log the query string of a GET request. If you can then get the server to say include that logfile as a php file, it will execute the embedded PHP. Of course the real vuln isn't logging GET params (it's convincing the server to include the logfile as .php), but I thought it was worth pointing out.
dfranke 16y ago
I think that in 2011, checking referer headers can be considered an acceptable form of CSRF prevention. Some very old browsers and plugins allow referer headers to be spoofed, but by now so many other vulnerabilities have been found in all those that if you're still using them then CSRF is the least of your problems.
mise 16y ago
Could someone explain to me briefly the method with which a token would be used, either in GET or POST?

by pak 16y ago

TimothyBurgess 16y ago

Indeed. I actually just finished implementing the secret token method throughout my app less than a minute ago. I have fullscreen and mobile versions... and without going into too much detail on exactly why in my particular case, it's cleaner and easier to use simple links (i.e., GET) for something like removing items from lists... so the token method is the only feasible solution to prevent something like I mentioned in my other comment (fake images and what not). But with the fullscreen version, since it's all AJAX and to make things easy on myself, I converted everything (except file uploads) to send data via POST (all links are generated by a function so instead of href it's onclick+ajax)... along with the token too of course... which was all a win-win because I lifted the data limit that GET used to impose as well. But anyway... today I learned that even though GET and POST are no different security-wise... always use a secret token when security is an issue... and it's best to use POST because it allows MUCH more data than GET.

tzs 16y ago

There is one security difference. POST doesn't leave the data in the URL bar at the top of the browser. I sure would rather a site submit my credit card via POST than via GET.

marcinw 16y ago
In addition to tzs' comment above, POST parameters do not get logged by the web server either (default Apache logging, etc), unless you're using a module like mod_security to log POST data. Besides, don't use GET for non-idempotent requests (those which change state). That's just webapp development 101. Edited for clarity.
- axiak 16y ago
  Either I'm completely misunderstanding your grammar, or you don't understand what idempotent means... idempotent and state-changing are almost opposites.
  - fhars 16y ago
    You don't understand what idempotent means. An action is idempotent if repeating it does not change the result. For example, multiplying by zero is idempotent, 0 * x is the same as 0 * 0 * 0 * 0 * x. But of course it changes something, as 0 * x is clearly not x in the general case. In the http case, GET and HEAD should not change any state (be safe and idempotent), PUT and DELETE should change state but be idempotent, and POST can do whatever it wants. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
    - axiak 16y ago
      Maybe you saw the text after @marcinw changed his text? I agree with you, of course I will say that most http GET actions I see are trivially idempotent -- that is to say they are idempotent because they don't change the state at all.
      - fhars 16y ago
        No, I saw the original version that cautioned against state changing idempotent GET requests. The changed version is actually worse, as it only cautions against non-idempotent GETs, which is not enough. State changing idempotent requests via GET are quite as bad. In fact, idempotency is irrelevant for GET, as GET requests should be safe, which trivially implies that they are idempotent. So requiring idempotency in addition to safety does nothing except making the prose harder to read.

KevBurnsJr 16y ago

Your `hidden form` exploit is moot for the example in the post <img src="http://example.com/do.php?action=delete&id=3 http://example.com/do.php?action=delete&id=3 />

tptacek 16y ago

Nope, that's exactly what I came here to say. Thanks! People conflate CSRF-ability with destructive GET operations because a lot of apps that are pervasively CSRF-able also happen to have lots of inadvertant destructive GET's, but the bad GET endpoints are a reliability flaw more than a security flaw.

andrewvc 16y ago

That's true 99.99% of the time. However, just to play devil's advocate, there is a class of attacks based around injecting code into logfiles since they'll log the query string of a GET request. If you can then get the server to say include that logfile as a php file, it will execute the embedded PHP. Of course the real vuln isn't logging GET params (it's convincing the server to include the logfile as .php), but I thought it was worth pointing out.

dfranke 16y ago

I think that in 2011, checking referer headers can be considered an acceptable form of CSRF prevention. Some very old browsers and plugins allow referer headers to be spoofed, but by now so many other vulnerabilities have been found in all those that if you're still using them then CSRF is the least of your problems.

mise 16y ago

Could someone explain to me briefly the method with which a token would be used, either in GET or POST?