From: John Black on
On 02/22/2010 11:42 PM, Michael Shadle wrote:
> The difference here is you can at least have some control over the data
> and expect it in a certain fashion. Also the behavior of cookies vs. get
> vs. post are different (cookies have length and expiration limits, get
> has length limits, post has server confgured limits)

The cookie and post/get part is all mixed up now :)

I use $_COOKIE when I want cookie information but I know that the data
is not to be trusted and is easily fabricated.

When reading get or post I just use $_REQUEST nowadays because I don't
have to care how the submitting form is written. This makes my form
handling data more portable.

--
John
You may say I'm a dreamer, but I'm not the only one,
I hope some day you'll join us, And the world will live as one.
[John Lennon]
From: Ashley Sheridan on
On Mon, 2010-02-22 at 23:49 +0100, John Black wrote:

> On 02/22/2010 11:42 PM, Michael Shadle wrote:
> > The difference here is you can at least have some control over the data
> > and expect it in a certain fashion. Also the behavior of cookies vs. get
> > vs. post are different (cookies have length and expiration limits, get
> > has length limits, post has server confgured limits)
>
> The cookie and post/get part is all mixed up now :)
>
> I use $_COOKIE when I want cookie information but I know that the data
> is not to be trusted and is easily fabricated.
>
> When reading get or post I just use $_REQUEST nowadays because I don't
> have to care how the submitting form is written. This makes my form
> handling data more portable.
>
> --
> John
> You may say I'm a dreamer, but I'm not the only one,
> I hope some day you'll join us, And the world will live as one.
> [John Lennon]
>


As many people have mentioned already, there's absolutely no security
risk of using $_REQUEST over $_POST or $_GET. I generally use $_REQUEST
unless I am specifically coding something that needs me to send data
over both post and get at the same time.

The thing is, just make sure you sanitise all the data that comes from
the browser. That includes cookie values, post data, etc. Proper
sanitisation is crucial and necessary, and no amount of obscurity about
how you are getting your data will help.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: Richard on
Hi,

Well people better than me (how is that possible?!) have said that
$_REQUEST has the potential to open your app up to security
vulnerabilities, and that it should be avoided because of that. Here's
a post from Stephan Esser about it on the PHP-Internals list:

http://www.mail-archive.com/internals(a)lists.php.net/msg32832.html

Stephan heads up the Hardened-PHP project and when it comes to
security, I don't know of anyone better. So, if he advises not to use
_REQUEST, it's a good idea to follow that advice.

--
Richard Heyes
From: Ashley Sheridan on
On Tue, 2010-02-23 at 09:19 +0000, Richard wrote:

> Hi,
>
> Well people better than me (how is that possible?!) have said that
> $_REQUEST has the potential to open your app up to security
> vulnerabilities, and that it should be avoided because of that. Here's
> a post from Stephan Esser about it on the PHP-Internals list:
>
> http://www.mail-archive.com/internals(a)lists.php.net/msg32832.html
>
> Stephan heads up the Hardened-PHP project and when it comes to
> security, I don't know of anyone better. So, if he advises not to use
> _REQUEST, it's a good idea to follow that advice.
>
> --
> Richard Heyes
>


Well, he's only saying there that it 'most probably vulnerable' and
mentions that cookies can overwrite post and get data. This isn't a
problem with $_REQUEST itself but rather an applications' use of it. So
what if someone crafts a cookie to send a bad value. If someone has the
gen to do that, then they are going to know how to send get and post
values as well. Only decent sanitisation will be able to protect against
this.

If the order of override variables in $_REQUEST is such an issue too,
use the request_order ini setting to specify the order you'd prefer.

I've never had any issues with using $_REQUEST, but found a lot of
advantages to using it, as I often use a mix of data sources in the same
app.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: "Bob McConnell" on
From: Rene Veerman [mailto:rene7705(a)gmail.com]
> On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle
>>
>> Single quotes is best, correct to prevent sql injection?
>
> sql injection fixing is an evolving art, but you can start by pushing
> all variables that can be changed by end-users going into a database
> through a marshalling-function fixSQLinjectionToDB ($var) { return
> addslashes($var); };
> addslashes is the minimum fix i believe, but google around and give us
> back the up-to-date uber-fix-function please :)

Slash is the wrong character. The correct SQL escape character is the
single quote.

The best way to prepare text fields is to use the DB specific escape
functions on each text field before assembling the command string, i.e.
pg_escape_string(). But that is after all fields have been sanitized and
validated.

In addition, if magic_quotes is turned on, you also need to remove them
before doing the validation. The contributed notes in the online manual
have some good suggestions on how to accomplish this.

Bob McConnell