php-general Digest 18 Jun 2006 01:04:47 -0000 Issue 4191
Topics (messages 238186 through 238211):
Re: GET, POST, REQUEST
238186 by: Satyam
238187 by: David Tulloh
238188 by: tedd
238189 by: Mark Charette
238194 by: Ben Ramsey
238195 by: Anthony Ettinger
238196 by: Chris Peterman
238198 by: Anthony Ettinger
238199 by: Ben Ramsey
238200 by: Martin Marques
238201 by: Martin Marques
238202 by: Satyam
238203 by: Martin Marques
238204 by: Ben Ramsey
238205 by: Ben Ramsey
238206 by: Ben Ramsey
238207 by: Ben Ramsey
238208 by: Manuel Lemos
238209 by: Rory Browne
238210 by: Rory Browne
238211 by: Manuel Lemos
Re: file_exists() behind firewall
238190 by: Ahmed Saad
Re: transfer file
238191 by: Ahmed Saad
Re: Need to recompile php 4.3.4
238192 by: Mauricio Pellegrini
Re: serving video files with php
238193 by: Ahmed Saad
Re: Serving a graphic downloads it instead of displaying it
238197 by: Frank Arensmeier
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
In general, user input should never be trusted. Someone once told me that
if you ask for yes or no, you should always validate for yes, no and don't
know (of course, this was before windowed environments where the users can
only click what you offer them).
In a web environment you have a higher ratio of untrained users. In the old
days, when you deployed an application, you planned for user training. You
have none of that here, anyone can join in and, many times, anonymously so
they know they won't even be blamed for anything irresponsible that they can
do on your system, you can't even count on holding users responsible for
anything.
Finally, there is intentional misschief, and there is lots of it.
Suppose you have a form which you submit in a post so the user can't see
what's being transmitted. Nothing prevents someone to view the source of
the page, pick the input field names and assemble a fake request. If you
read it from $_REQUEST instead of from $_POST you are even exposed to this
get request attack which is easier than faking a post. For example, when I
joined some organization, their web site asked some data, amongst it the
number of my ID card. ID cards have check-digit validation and it rejected
mine. Indeed, mine is not a regular national ID card but an alien resident
card which uses a different algorithm for validation. I assembled a get
request in a URL with all the data of the form, including my alien card, and
the system accepted it! So, do never trust data coming from the browser
even if you have put validation on your pages, and if it is meant to come as
a POST, make sure it comes from one.
And we are not even talking about malicious requests. Usually there is not
much script in between user input and the database. If there is no
validation, it is quite open to SQL injection attacks, that is, chaining a
SQL instruction to a data field and have it execute along your original one.
You can read far more about this in places like http://phpsecurity.org/ or
http://phpsec.org/ and I'm sure other list members will supply more.
Satyam
----- Original Message -----
From: "Martin Marques" <[email protected]>
To: <[email protected]>
Sent: Saturday, June 17, 2006 1:52 PM
Subject: [PHP] GET, POST, REQUEST
Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
array, which looked like a solution to having to check in GET and POST
data (I'm not sure if it will really have an impact on my program yet).
The thing is, I also saw this description:
Variables provided to the script via the GET, POST, and COOKIE input
mechanisms, and which therefore cannot be trusted.
Now, why shouldn't it be trusted?
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--------------------------------------------------------------------------------
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Martin Marques wrote:
> Yesterday when reading some doc on PHP I noticed the $_REQUEST
> predefined array, which looked like a solution to having to check in GET
> and POST data (I'm not sure if it will really have an impact on my
> program yet).
Yes, request is simply a merge of these arrays. It can be very useful
and tends to be rather under used in PHP examples.
>
> The thing is, I also saw this description:
>
> Variables provided to the script via the GET, POST, and COOKIE input
> mechanisms, and which therefore cannot be trusted.
>
> Now, why shouldn't it be trusted?
>
No user data should be trusted. It's possible for the user to provide
absolutely anything in these variables and unless you check it, you have
no idea what you have actually received. This covers everything
provided from the user, get, post and cookie variables, $_REQUEST as an
amalgamation of these three should be equally untrusted.
David
--- End Message ---
--- Begin Message ---
At 8:52 AM -0300 6/17/06, Martin Marques wrote:
>Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
>array, which looked like a solution to having to check in GET and POST data
>(I'm not sure if it will really have an impact on my program yet).
>
>The thing is, I also saw this description:
>
>Variables provided to the script via the GET, POST, and COOKIE input
>mechanisms, and which therefore cannot be trusted.
>
>Now, why shouldn't it be trusted?
Martin:
Lot's of reasons why you shouldn't trust user input.
The best book I've read covering the subject has been:
Essential PHP Security (Paperback)
by Chris Shiflett
<http://www.amazon.com/gp/product/059600656X/sr=8-1/qid=1150552179/ref=pd_bbs_1/102-6441978-4633725?%5Fencoding=UTF8>
In my opinion, it's a "must read" if you care about security.
tedd
PS: The author also attends this list
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Satyam wrote:
In general, user input should never be trusted. Someone once told me
that if you ask for yes or no, you should always validate for yes, no
and don't know (of course, this was before windowed environments where
the users can only click what you offer them).
Users can submit whatever they please; they are not limited by "click
what you offer them" via web input.
Always: user input can never be trusted.
--- End Message ---
--- Begin Message ---
On 6/17/06 9:30 AM, David Tulloh wrote:
Martin Marques wrote:
Yesterday when reading some doc on PHP I noticed the $_REQUEST
predefined array, which looked like a solution to having to check in GET
and POST data (I'm not sure if it will really have an impact on my
program yet).
Yes, request is simply a merge of these arrays. It can be very useful
and tends to be rather under used in PHP examples.
Using $_REQUEST is similar to using register_globals. You simply cannot
trust the origin of the data. It's possible that a variable by the name
of "foo" exists as a cookie, POST value, and GET value. If you use
$_REQUEST, you cannot be assured that the value you are getting is from
the scope you intend to retrieve it.
Consider the following script:
<?php
setcookie('foo', 'cookie');
?>
<form method="POST" action="<?php echo $_SERVER['SCRIPT_NAME']; ?>?foo=get">
<input type="text" name="foo" value="post" />
<input type="submit" />
</form>
<pre>
<?php
var_dump($_REQUEST);
var_dump($_GET);
var_dump($_POST);
var_dump($_COOKIE);
?>
</pre>
Save this to a PHP file, access it through a Web browser, and click on
the "Submit" button. You'll see four different arrays that output the
$_REQUEST, $_GET, $_POST, and $_COOKIE values. The problem is that the
$_REQUEST array contains only one value for "foo," but we know it exists
in all scopes with different values.
A user that knows this can make use of this knowledge to add a GET
variable to the query string, add a cookie header to the request, or
spoof the form with other values in POST than you intend.
So, there are two things you must do here: 1) always check the origin of
your data (don't use $_REQUEST, even if it seems convenient), and 2)
always check that the input received is input expected (filter the input).
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
simply using $_POST is by no means more secure than $_REQUEST.
On 6/17/06, Ben Ramsey <[EMAIL PROTECTED]> wrote:
On 6/17/06 9:30 AM, David Tulloh wrote:
> Martin Marques wrote:
>> Yesterday when reading some doc on PHP I noticed the $_REQUEST
>> predefined array, which looked like a solution to having to check in GET
>> and POST data (I'm not sure if it will really have an impact on my
>> program yet).
>
> Yes, request is simply a merge of these arrays. It can be very useful
> and tends to be rather under used in PHP examples.
Using $_REQUEST is similar to using register_globals. You simply cannot
trust the origin of the data. It's possible that a variable by the name
of "foo" exists as a cookie, POST value, and GET value. If you use
$_REQUEST, you cannot be assured that the value you are getting is from
the scope you intend to retrieve it.
Consider the following script:
<?php
setcookie('foo', 'cookie');
?>
<form method="POST" action="<?php echo $_SERVER['SCRIPT_NAME']; ?>?foo=get">
<input type="text" name="foo" value="post" />
<input type="submit" />
</form>
<pre>
<?php
var_dump($_REQUEST);
var_dump($_GET);
var_dump($_POST);
var_dump($_COOKIE);
?>
</pre>
Save this to a PHP file, access it through a Web browser, and click on
the "Submit" button. You'll see four different arrays that output the
$_REQUEST, $_GET, $_POST, and $_COOKIE values. The problem is that the
$_REQUEST array contains only one value for "foo," but we know it exists
in all scopes with different values.
A user that knows this can make use of this knowledge to add a GET
variable to the query string, add a cookie header to the request, or
spoof the form with other values in POST than you intend.
So, there are two things you must do here: 1) always check the origin of
your data (don't use $_REQUEST, even if it seems convenient), and 2)
always check that the input received is input expected (filter the input).
--
Ben Ramsey
http://benramsey.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html
--- End Message ---
--- Begin Message ---
But it would seem that using $_POST cuts down on the number of possible ways
that something bad could happen, doesn't it? (Someone correct me if I am
wrong, I am by no means a security or PHP expert, though working towards
both :D)
On Saturday 17 June 2006 14:51, Anthony Ettinger wrote:
> simply using $_POST is by no means more secure than $_REQUEST.
>
> On 6/17/06, Ben Ramsey <[EMAIL PROTECTED]> wrote:
> > On 6/17/06 9:30 AM, David Tulloh wrote:
> > > Martin Marques wrote:
> > >> Yesterday when reading some doc on PHP I noticed the $_REQUEST
> > >> predefined array, which looked like a solution to having to check in
> > >> GET and POST data (I'm not sure if it will really have an impact on my
> > >> program yet).
> > >
> > > Yes, request is simply a merge of these arrays. It can be very useful
> > > and tends to be rather under used in PHP examples.
> >
> > Using $_REQUEST is similar to using register_globals. You simply cannot
> > trust the origin of the data. It's possible that a variable by the name
> > of "foo" exists as a cookie, POST value, and GET value. If you use
> > $_REQUEST, you cannot be assured that the value you are getting is from
> > the scope you intend to retrieve it.
> >
> > Consider the following script:
> >
> > <?php
> > setcookie('foo', 'cookie');
> > ?>
> > <form method="POST" action="<?php echo $_SERVER['SCRIPT_NAME'];
> > ?>?foo=get"> <input type="text" name="foo" value="post" />
> > <input type="submit" />
> > </form>
> > <pre>
> > <?php
> > var_dump($_REQUEST);
> > var_dump($_GET);
> > var_dump($_POST);
> > var_dump($_COOKIE);
> > ?>
> > </pre>
> >
> > Save this to a PHP file, access it through a Web browser, and click on
> > the "Submit" button. You'll see four different arrays that output the
> > $_REQUEST, $_GET, $_POST, and $_COOKIE values. The problem is that the
> > $_REQUEST array contains only one value for "foo," but we know it exists
> > in all scopes with different values.
> >
> > A user that knows this can make use of this knowledge to add a GET
> > variable to the query string, add a cookie header to the request, or
> > spoof the form with other values in POST than you intend.
> >
> > So, there are two things you must do here: 1) always check the origin of
> > your data (don't use $_REQUEST, even if it seems convenient), and 2)
> > always check that the input received is input expected (filter the
> > input).
> >
> > --
> > Ben Ramsey
> > http://benramsey.com/
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> Anthony Ettinger
> Signature: http://chovy.dyndns.org/hcard.html
--
~ Chris "Kyral" Peterman
Computer Science Undergraduate
Clarkson University
Associate Member of the Free Software Foundation
Ubuntu Member
pgpWnjgNQomEM.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
it's more like painting the color of your front door, but still
leaving it unlocked. It doesn't change the fact that people can still
open the door.
every input field needs to be validated regardless of get vs. post.
the web developer toolbar for firefox can easily convert all form
fields to one or the other, so it's trivial to send a get request as
post, and vice-versa.
On 6/17/06, Chris Peterman <[EMAIL PROTECTED]> wrote:
But it would seem that using $_POST cuts down on the number of possible ways
that something bad could happen, doesn't it? (Someone correct me if I am
wrong, I am by no means a security or PHP expert, though working towards
both :D)
On Saturday 17 June 2006 14:51, Anthony Ettinger wrote:
> simply using $_POST is by no means more secure than $_REQUEST.
>
> On 6/17/06, Ben Ramsey <[EMAIL PROTECTED]> wrote:
> > On 6/17/06 9:30 AM, David Tulloh wrote:
> > > Martin Marques wrote:
> > >> Yesterday when reading some doc on PHP I noticed the $_REQUEST
> > >> predefined array, which looked like a solution to having to check in
> > >> GET and POST data (I'm not sure if it will really have an impact on my
> > >> program yet).
> > >
> > > Yes, request is simply a merge of these arrays. It can be very useful
> > > and tends to be rather under used in PHP examples.
> >
> > Using $_REQUEST is similar to using register_globals. You simply cannot
> > trust the origin of the data. It's possible that a variable by the name
> > of "foo" exists as a cookie, POST value, and GET value. If you use
> > $_REQUEST, you cannot be assured that the value you are getting is from
> > the scope you intend to retrieve it.
> >
> > Consider the following script:
> >
> > <?php
> > setcookie('foo', 'cookie');
> > ?>
> > <form method="POST" action="<?php echo $_SERVER['SCRIPT_NAME'];
> > ?>?foo=get"> <input type="text" name="foo" value="post" />
> > <input type="submit" />
> > </form>
> > <pre>
> > <?php
> > var_dump($_REQUEST);
> > var_dump($_GET);
> > var_dump($_POST);
> > var_dump($_COOKIE);
> > ?>
> > </pre>
> >
> > Save this to a PHP file, access it through a Web browser, and click on
> > the "Submit" button. You'll see four different arrays that output the
> > $_REQUEST, $_GET, $_POST, and $_COOKIE values. The problem is that the
> > $_REQUEST array contains only one value for "foo," but we know it exists
> > in all scopes with different values.
> >
> > A user that knows this can make use of this knowledge to add a GET
> > variable to the query string, add a cookie header to the request, or
> > spoof the form with other values in POST than you intend.
> >
> > So, there are two things you must do here: 1) always check the origin of
> > your data (don't use $_REQUEST, even if it seems convenient), and 2)
> > always check that the input received is input expected (filter the
> > input).
> >
> > --
> > Ben Ramsey
> > http://benramsey.com/
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> Anthony Ettinger
> Signature: http://chovy.dyndns.org/hcard.html
--
~ Chris "Kyral" Peterman
Computer Science Undergraduate
Clarkson University
Associate Member of the Free Software Foundation
Ubuntu Member
--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html
--- End Message ---
--- Begin Message ---
On 6/17/06 3:07 PM, Anthony Ettinger wrote:
it's more like painting the color of your front door, but still
leaving it unlocked. It doesn't change the fact that people can still
open the door.
every input field needs to be validated regardless of get vs. post.
the web developer toolbar for firefox can easily convert all form
fields to one or the other, so it's trivial to send a get request as
post, and vice-versa.
Which is why, if you read the last paragraph of my post, it said that
there are two things you must do: 1) always check the origin of the
input and 2) always filter (validate) the input.
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
On Sat, 17 Jun 2006 15:01:23 +0200, "Satyam" <[EMAIL PROTECTED]> wrote:
> In general, user input should never be trusted. Someone once told me that
> if you ask for yes or no, you should always validate for yes, no and don't
> know (of course, this was before windowed environments where the users can
> only click what you offer them).
Yes, I do validation. Incoming data is insearted to objects via methods that
validate it first.
What I was asking is why the $_REQUEST is untrueted while $_POST and $_GET are
(or at least the are not explicitly untrusted).
--
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
On Sat, 17 Jun 2006 14:25:30 -0400, Ben Ramsey <[EMAIL PROTECTED]> wrote:
> On 6/17/06 9:30 AM, David Tulloh wrote:
>> Martin Marques wrote:
>>> Yesterday when reading some doc on PHP I noticed the $_REQUEST
>>> predefined array, which looked like a solution to having to check in
> GET
>>> and POST data (I'm not sure if it will really have an impact on my
>>> program yet).
>>
>> Yes, request is simply a merge of these arrays. It can be very useful
>> and tends to be rather under used in PHP examples.
>
> Using $_REQUEST is similar to using register_globals. You simply cannot
> trust the origin of the data. It's possible that a variable by the name
> of "foo" exists as a cookie, POST value, and GET value. If you use
> $_REQUEST, you cannot be assured that the value you are getting is from
> the scope you intend to retrieve it.
OK, now it's clear for me!
Thanks for the enlightenment.
--
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
$_REQUEST is not particularly dangerous compared to $_GET or $_POST, it is
just one more validation you can make: if you expect data from a POST,
check it from POST. That's why I mentioned that form where I entered my
personal data, the form was sent as POST but it took a faked GET from me,
that's one mistake, but the worst was that the validation done in JavaScript
on the client side was not repeated on the server side so it let my ID card
number through. If they had done the data validation, it would have
rejected my data whether it came via GET or POST.
Your application might require that flexibility or accepting data via POST
or GET, in which case, it is just fine. Contrary to another post I've
read, there is nothing good of register_globals, that is why it is now
defaulted to off and kept for compatibility, though highly discouraged.
There is nothing intrinsically wrong with $_REQUEST, it is slightly more
vulnerable than differentiating POSTs from GETs, but it is not the worst you
can do
Satyam
----- Original Message -----
From: "Martin Marques" <[email protected]>
To: "Satyam" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Saturday, June 17, 2006 11:22 PM
Subject: Re: [PHP] GET, POST, REQUEST
On Sat, 17 Jun 2006 15:01:23 +0200, "Satyam" <[EMAIL PROTECTED]> wrote:
In general, user input should never be trusted. Someone once told me
that
if you ask for yes or no, you should always validate for yes, no and
don't
know (of course, this was before windowed environments where the users
can
only click what you offer them).
Yes, I do validation. Incoming data is insearted to objects via methods
that validate it first.
What I was asking is why the $_REQUEST is untrueted while $_POST and $_GET
are (or at least the are not explicitly untrusted).
--
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Sat, 17 Jun 2006 09:55:05 -0400, tedd <[EMAIL PROTECTED]> wrote:
> At 8:52 AM -0300 6/17/06, Martin Marques wrote:
>>Yesterday when reading some doc on PHP I noticed the $_REQUEST predefined
> array, which looked like a solution to having to check in GET and POST data
> (I'm not sure if it will really have an impact on my program yet).
>>
>>The thing is, I also saw this description:
>>
>>Variables provided to the script via the GET, POST, and COOKIE input
> mechanisms, and which therefore cannot be trusted.
>>
>>Now, why shouldn't it be trusted?
>
> Martin:
>
> Lot's of reasons why you shouldn't trust user input.
OK, let's clear something out (which I didn't put in my original mail, and
should have).
I know user input shouldn't be trusted. What I want to know is IF and WHY
$_REQUEST should be more untrusted then $_POST or $_GET.
--
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
On 6/17/06 5:25 PM, Martin Marques wrote:
I know user input shouldn't be trusted. What I want to know is IF and WHY
$_REQUEST should be more untrusted then $_POST or $_GET.
It's untrusted because you know the data comes from a request. It's more
untrusted than GET, POST, or COOKIE because you can't tell the scope of
the data.
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
On 6/17/06 5:25 PM, Martin Marques wrote:
I know user input shouldn't be trusted. What I want to know is IF and WHY
$_REQUEST should be more untrusted then $_POST or $_GET.
It's untrusted because you know the data comes from a request. It's more
untrusted than GET, POST, or COOKIE because you can't tell the scope of
the data.
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
On 6/17/06 5:34 PM, Satyam wrote:
Your application might require that flexibility or accepting data via
POST or GET, in which case, it is just fine. Contrary to another post
I've read, there is nothing good of register_globals, that is why it is
now defaulted to off and kept for compatibility, though highly
discouraged. There is nothing intrinsically wrong with $_REQUEST, it is
slightly more vulnerable than differentiating POSTs from GETs, but it is
not the worst you can do
I never said there was anything good about register_globals. In fact, I
was implying that it was bad. With register_globals, you can't tell
whether the variable $foo is local, global, from POST, from GET, from
COOKIE, etc. I compared $_REQUEST to register_globals because it behaves
similarly: you still don't know whether $_REQUEST['foo'] comes from
POST, GET, or COOKIE. The good thing is that you at least know it comes
from an HTTP request, so you know not to trust anything from it.
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
On 6/17/06 5:34 PM, Satyam wrote:
Your application might require that flexibility or accepting data via
POST or GET, in which case, it is just fine. Contrary to another post
I've read, there is nothing good of register_globals, that is why it is
now defaulted to off and kept for compatibility, though highly
discouraged. There is nothing intrinsically wrong with $_REQUEST, it is
slightly more vulnerable than differentiating POSTs from GETs, but it is
not the worst you can do
I never said there was anything good about register_globals. In fact, I
was implying that it was bad. With register_globals, you can't tell
whether the variable $foo is local, global, from POST, from GET, from
COOKIE, etc. I compared $_REQUEST to register_globals because it behaves
similarly: you still don't know whether $_REQUEST['foo'] comes from
POST, GET, or COOKIE. The good thing is that you at least know it comes
from an HTTP request, so you know not to trust anything from it.
--
Ben Ramsey
http://benramsey.com/
--- End Message ---
--- Begin Message ---
on 06/17/2006 07:10 PM Ben Ramsey said the following:
> On 6/17/06 5:34 PM, Satyam wrote:
>> Your application might require that flexibility or accepting data via
>> POST or GET, in which case, it is just fine. Contrary to another
>> post I've read, there is nothing good of register_globals, that is why
>> it is now defaulted to off and kept for compatibility, though highly
>> discouraged. There is nothing intrinsically wrong with $_REQUEST, it
>> is slightly more vulnerable than differentiating POSTs from GETs, but
>> it is not the worst you can do
>
> I never said there was anything good about register_globals. In fact, I
> was implying that it was bad. With register_globals, you can't tell
> whether the variable $foo is local, global, from POST, from GET, from
> COOKIE, etc. I compared $_REQUEST to register_globals because it behaves
> similarly: you still don't know whether $_REQUEST['foo'] comes from
> POST, GET, or COOKIE. The good thing is that you at least know it comes
> from an HTTP request, so you know not to trust anything from it.
Mind me for a little disagreement, but the problem of register globals
isn't with not being able to distinguish between client side originated
global variables like GET POST COOKIE, but rather from not being able to
distinguish client side and server side original global variables, which
includes environment variables and session variables.
Having register globals enabled per se does not make any site
vulnerable. What can potentially make a site vulnerable is using code
that fetches session and environment variables from global variables
instead of $_SESSION, $_SERVER and $_ENV (or GetEnv).
As long as you use these superglobals for accessing server side
originated variables, it does not matter if you use $_REQUEST instead of
$_GET, $_POST or $_COOKIE because all of these client side variables can
be forged by an eventual attacker with a cooked request.
So, a secure application always has to validate values from client side
originated variables, independently if the values were retrieved from
$_GET, $_POST, $_COOKIE or $_REQUEST .
As for server side originated variables, these do not need to be
validated if you get them from $_SESSION, $_SERVER and $_ENV .
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
On 6/18/06, Ben Ramsey <[EMAIL PROTECTED]> wrote:
On 6/17/06 5:34 PM, Satyam wrote:
> Your application might require that flexibility or accepting data via
> POST or GET, in which case, it is just fine. Contrary to another post
> I've read, there is nothing good of register_globals, that is why it is
> now defaulted to off and kept for compatibility, though highly
> discouraged. There is nothing intrinsically wrong with $_REQUEST, it is
> slightly more vulnerable than differentiating POSTs from GETs, but it is
> not the worst you can do
I never said there was anything good about register_globals. In fact, I
was implying that it was bad. With register_globals, you can't tell
whether the variable $foo is local, global, from POST, from GET, from
COOKIE, etc. I compared $_REQUEST to register_globals because it behaves
similarly: you still don't know whether $_REQUEST['foo'] comes from
POST, GET, or COOKIE. The good thing is that you at least know it comes
from an HTTP request, so you know not to trust anything from it.
You're in a bad state of affairs when the security of your application comes
down to whether the input came from POST, GET, or COOKIE.
I wouldn't compare register_globals to $_REQUEST. The problem with
register_globals is that it injects variables into your script. $_REQUEST
doesn't do that.
There are pros and cons for each: $_REQUEST is more flexable - $_GET and
$_POST are more self-documenting - if you see $_POST, you know that the info
came from a POST form, where as $_GET variables could be <a
href="x.php?name=value">like
this</a>.
If your security is so bad in the first place that your use of $_REQUEST
instead of $_POSTcauses a vulnerability, then it's time for a serious code
audit.
Good code won't be vulnerable to register_globals either, but having
register_globals on is a security problem because there are security flaws
that can only be exploited when register_globals is enabled.
--- End Message ---
--- Begin Message ---
So, a secure application always has to validate values from client side
originated variables, independently if the values were retrieved from
$_GET, $_POST, $_COOKIE or $_REQUEST .
You should always validate ALL external variables.
As for server side originated variables, these do not need to be
validated if you get them from $_SESSION, $_SERVER and $_ENV .
THIS IS NOT TRUE.
Some $_SERVER variables can be influenced by the client ( eg
$_SERVER['PATH_INFO'], being one example) (same for $_ENV)
$_SESSION validation is equally important, but slightly different. You need
to make sure ( for example ) that your sessions aren't being hijacked.
--- End Message ---
--- Begin Message ---
Hello,
on 06/17/2006 08:35 PM Rory Browne said the following:
>> So, a secure application always has to validate values from client side
>> originated variables, independently if the values were retrieved from
>> $_GET, $_POST, $_COOKIE or $_REQUEST .
>
>
> You should always validate ALL external variables.
That is what I said! ;-)
> As for server side originated variables, these do not need to be
>> validated if you get them from $_SESSION, $_SERVER and $_ENV .
>
>
> THIS IS NOT TRUE.
>
> Some $_SERVER variables can be influenced by the client ( eg
> $_SERVER['PATH_INFO'], being one example) (same for $_ENV)
Sure, that is true, I was not thinking of variables associated with the
HTTP request itself, but rather other that are constant Web server wide.
> $_SESSION validation is equally important, but slightly different. You need
> to make sure ( for example ) that your sessions aren't being hijacked.
That is another story. Still, the point here is that you can have
register globals turned on and safely read session variables from
$_SESSION without further validation because the session variable values
were once set by the server side application, you do not need to
validate them on each request like client side originated variables.
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
On 17/06/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
I dunno if AJAX will let you quit partway through, but you could
definitely do this with the lean and mean hand-coded XmlHttpRequest
object and sending HEAD to see if the URL is "there" or not.
For security reasons, an XMLHttpRequest objects can only communicate
with the originating server. And even if it could, it supports only
HTTP (so the PDFs have to be put on a web server behind the firewall).
You might want to consider a client-side technology that supports more
protocols than just HTTP (e.g a signed Java applet that prompts users
for the necessary permissions, ?) if that's not the case (SSH, or even
in a database.. )
/ahmed
--- End Message ---
--- Begin Message ---
Hi Richard..
On 15/06/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
HTTP just plain ain't gonna let you open a file up for "writing" --
thank god.
I think it does in form of PUT requests..
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
(apparently not supported by PHP streams(?))
Security restrictions to keep away black hats might be enforced
through HTTP authentication.
/ahmed
--- End Message ---
--- Begin Message ---
Well, this is what I've done.
First, made a test on a Fedora Core 2 installation by running
./configure --with etc,etc and --enable-bcmath
Then executed make in order to generate executables but
*DID NOT* run make install
After that, copied manually libphp4.so from the build directory to
libexec under apache tree and restarted apache. It worked just fine!!
after that bcmath was shown by phpinfo() as been loaded.
Then, did the same steps on the production server
( the diference here is that the operating System is Suse 8.2 Not Fedora
core 2.)
Repeated all steps as before and bcmath was enabled. But phpinfo()
does not show the correct Build date for Php ( which should be today )
neither shows the configure option with the --enable-bcmath switch
but it does show a section below in wich states that bcmath support is
enabled.
And of course tested with some php module that wasn't running before,
and now it works, so I think everything is fine.
These are the steps i used
1. re-configure (./configure --enable-bcmath or what ever other switch)
2. then run the Make utility
3. after that manually copy libphp4.so to libexec under apache tree.
One last comment: The Zend optimizer continues to work perfectly
after the whole process
I would like to hear some experienced user comments about this
Thanks
Mauricio
On Fri, 2006-06-16 at 21:48, chris smith wrote:
> On 6/17/06, Mauricio Pellegrini <[EMAIL PROTECTED]> wrote:
> > Hi ,
> > In order to enable bcmath I need to recompile php 4.3.4 on suse 8.2.
> >
> >
> > but , I would like to preserve the actual installation just in case
> > anything goes wrong ( as this is my production server)
> >
> > What files should I backup / restore if after compilation php is not
> > working?
> >
> >
> > My actual installation consists of php 4.3.4 With the Zend Optimizer
> > and apache 1.329
>
> Install them in different paths (configure --prefix=...), it will make
> it a lot easier.
>
> If you installed originally from rpms, you should be able to find
> where it put stuff (rpm -qpl php I think).. If you compiled then
> phpinfo will show you the original prefix and you can backup that
> structure.
>
> Not sure whether ZO will cope with that, but I guess you'll soon find out ;)
>
> --
> Postgresql & php tutorials
> http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
On 15/06/06, Andras Kende <[EMAIL PROTECTED]> wrote:
Is there any drawback servings video files through php downloader script on
high load site?
the question is why you want that?
If you want to "log" how many times/when the video files were viewed,
you can send the request to a PHP script that does the logging first
and then send an HTTP redirection to the actual video file (but
actually users could bypass logging if they head directly for the
video URL)..
If you manipulate the video file on-the-fly, I think you might need to
consider caching with the above solution ..
/ahmed
--- End Message ---
--- Begin Message ---
Maybe it is not essential, but shouldn't it say:
header("Content-type: image/jpeg");
notice "jpeg" - not "jpg".
/frank
16 jun 2006 kl. 22.15 skrev Mariano Guadagnini:
Brian Dunning wrote:
I'm trying to serve up a jpeg like this:
header("Content-type: image/jpg");
readfile('images/banner-ad.jpg');
It works on other browsers, but on Safari it downloads the graphic
like a file, rather than displaying it. What's up with that????
--PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.0/367 - Release Date:
16/06/2006
Maybe you can try to embed the image in a blank html, inside <img>
tag for example, to show only the image you want.
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.0/367 - Release Date:
16/06/2006
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
----------------------------------
Frank Arensmeier
Marketing Support & Webmaster
NIKE Hydraulics AB
Box 1107
631 80 Eskilstuna
Sweden
phone +46 - (0)16 16 82 34
fax +46 - (0)16 13 93 16
[EMAIL PROTECTED]
www.nikehydraulics.se
--- End Message ---
