Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58048
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
Message-ID: <4F4818FC.9020104@garfieldtech.com>
Date: Fri, 24 Feb 2012 17:10:52 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGovj_PbjoB78kXvZcaSkx3qQziMXX7ezVmzYSPHQbJL7uu7VA@mail.gmail.com> <8D8E9A0839FE464FBBDF2B499DAFA596@gmail.com> <CAGovj_OA29qv0MvpFwaT6EF4h_+CYuirNY8nLBaqGurkdO3Afw@mail.gmail.com> <88ad33db205558862288b3114ef4c391.squirrel@www.l-i-e.com> <4F480C5B.30606@garfieldtech.com> <96462fbc4e243e75b11b455624ac4140.squirrel@www.l-i-e.com> <4F4811E6.4050201@garfieldtech.com> <CAFWS2+GEX-6yvbMmKi0ffco8LYc9fx94gdC0-18DLo2SxvcuNA@mail.gmail.com> <4F48153C.7040406@garfieldtech.com> <CAFWS2+HhmK3atTYOmsYRC=csOaKTcXTdVh7ucJvwiMS5J9W5qg@mail.gmail.com>
In-Reply-To: <CAFWS2+HhmK3atTYOmsYRC=csOaKTcXTdVh7ucJvwiMS5J9W5qg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] $_PARAMETERS Super Global Object
From: larry@garfieldtech.com (Larry Garfield)

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