At 11:07 PM +0100 2/22/10, John Black wrote:
On 02/22/2010 10:37 PM, Michael Shadle wrote:
On Mon, Feb 22, 2010 at 1:30 PM, David
Murphy<david@xxxxxxxxxxxxxxxxx> wrote:
Richard,
The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST,
they should ALL be treats as bad data until normalized and sanitized. The
claim that it opens a security hole is just false, that's like saying PHP
is insecure, its not it just allows for lazy coding such as $_REQUEST.
It represents a way for people to exploit coders who don't know any better.
Expecting a cookie value to come through in $_REQUEST but you could
override using a query string parameter makes for easy exploitation.
And how is this more secure? I can create a cookie, send post or get
on my client machine and send anything I want to the server. Just
because you are getting a cookie does not mean that you created it :)
So you might as well use request because the data can not be trusted
either way.
--
John
It is true that you cannot trust any data coming from a client (i.e.,
POST, GET, COOKIE, REQUEST, Whatever).
However, in trying to secure what you are doing it makes sense to
know specifically the origin of your data.
Additionally, if you know specifically where your data is coming
from, then there are no surprises as there can be by using REQUEST.
I am sure you realize that the data provided by a REQUEST can be
overridden by processes you may have not accounted for. For example,
while you are thinking that the data you're working on was provided
by one super global it actually was overridden by another can lead to
problems, including security.
One security directive is to keep the process simple and under
control. The more complicated you make it, the less secure it becomes
regardless of the method of data collection.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
