On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield<
[email protected]> wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield<
[email protected]>
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable, the other is not idempotent and not
cacheable.
I very much care which someone is using.
People exploiting security would *never* think of
caching/replaying/modifying a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!
er, no.
Please point out where I said that POST not a security risk. I am quite
sure I typed no such thing, so how you read such a thing I do not know. I
am genuinely curious to see how you managed to interpret anything I said as
"POST is secure because it won't be cached".
Well, I didn't actually say that you said any such thing. I picked up on:
"the other is not idempotent and not cacheable"
...which is obviously false, and I highlighted, in a security context,
how POSTs are cached, and should be treated with equal distrust as
GET, because both are suspect, user submitted, forms of data, subject
to exploiting.
-Ronabop
When systems are behaving properly, POST is not cached. I was referring to the RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
"Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource."
So strictly speaking its the response to a POST that is not (by default) cached. From a security perspective, yes, all incoming data should be viewed as a threat until proven otherwise, regardless of what part of the HTTP request it comes from or what superglobal PHP marshals it into by default.
--Larry Garfield