On 2/24/12 5:04 PM, Ronald Chmara wrote:
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield<la...@garfieldtech.com>  wrote:
On 2/24/12 4:48 PM, Ronald Chmara wrote:

On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield<la...@garfieldtech.com>
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to