Re: $_PARAMETERS Super Global Object

On 2/24/12 5:04 PM, Ronald Chmara wrote:

On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield<larry@garfieldtech.com> wrote:

On 2/24/12 4:48 PM, Ronald Chmara wrote:

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