| Magic quotes? Should I still be cautious? [message #176378] |
Thu, 29 December 2011 20:55  |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
I do not have control of my server (shared server).
echo get_magic_quotes_gpc(); returns True.
Should I still be cautious and use addslashes/stripslashes in case the
hosting company ever decides to change the settings?
Thanks
Mike
|
|
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176380 is a reply to message #176379] |
Thu, 29 December 2011 21:53  |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
On Thu, 29 Dec 2011 22:04:13 +0100, Michael Fesser <netizen(at)gmx(dot)de>
wrote:
> .oO(Michael Joel)
>
>> I do not have control of my server (shared server).
>>
>> echo get_magic_quotes_gpc(); returns True.
>> Should I still be cautious and use addslashes/stripslashes in case the
>> hosting company ever decides to change the settings?
>
> Yes. Check if magic quotes are enabled and use stripslashes() if they
> are to get the raw data.
>
> Micha
I have the script written. No I was going to go back and add the
addslashes/stripslashes.
But - the script is functioning right now without stripping slashes.
When I post database data to the page there are no slashes where you
would expect to find them. They seem to be removed automatically?
Mike
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176381 is a reply to message #176380] |
Thu, 29 December 2011 22:08 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
On Thu, 29 Dec 2011 16:53:17 -0500, Michael Joel <no(at)please(dot)com>
wrote:
> On Thu, 29 Dec 2011 22:04:13 +0100, Michael Fesser <netizen(at)gmx(dot)de>
> wrote:
>
>> .oO(Michael Joel)
>>
>>> I do not have control of my server (shared server).
>>>
>>> echo get_magic_quotes_gpc(); returns True.
>>> Should I still be cautious and use addslashes/stripslashes in case the
>>> hosting company ever decides to change the settings?
>>
>> Yes. Check if magic quotes are enabled and use stripslashes() if they
>> are to get the raw data.
>>
>> Micha
>
>
> I have the script written. No I was going to go back and add the
> addslashes/stripslashes.
>
> But - the script is functioning right now without stripping slashes.
> When I post database data to the page there are no slashes where you
> would expect to find them. They seem to be removed automatically?
>
> Mike
Sorry - meant to mention... I did verify magic quote gpc is on. So
does it automatically remove slashes as well?
Mike
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176382 is a reply to message #176379] |
Thu, 29 December 2011 22:22 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser schrieb:
> Check if magic quotes are enabled and use stripslashes() if they
> are to get the raw data.
There is also the sybase version of magic quotes which would require a
different kind of treatment. And if the data is an array you have to do
the keys as well, but only on the first level for a multidimensional
array if I remember right and -- well, all this is definitely way too
much trouble.
I prefer using the filter functions (http://de3.php.net/filter). They
allow to access the raw input data and thus to completely bypass any
magic quoting (as well as any modifications of the $_GET etc. arrays
done by the script):
/**
* Read a GPC value.
*
* @param string Name
* @return string|array|null Value or null
*/
function input( $name )
{
$name = str_replace( '.', '_', $name );
foreach ( array( INPUT_GET, INPUT_POST, INPUT_COOKIE ) as $source ):
$value = filter_input( $source, $name, FILTER_UNSAFE_RAW );
if ( $value === false ):
$value = filter_input( $source, $name,
FILTER_UNSAFE_RAW, FILTER_REQUIRE_ARRAY );
endif;
if ( $value !== null and $value !== false ):
return $value;
endif;
endforeach;
}
The above function can be modified to accept an explicit $source as
second argument and do away with the foreach. The first line addresses
the fact that PHP silently converts any dot in a variable name to an
underscore. My function allows using the "dotted" name. Once the value
is retrieved, it must, of course, be properly validated. Although the
filter functions provide such functionality, I prefer to do my own
validation.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176386 is a reply to message #176378] |
Thu, 29 December 2011 23:53 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 29 Dec 2011 15:55:10 -0500, Michael Joel wrote:
> I do not have control of my server (shared server).
>
> echo get_magic_quotes_gpc(); returns True.
> Should I still be cautious and use addslashes/stripslashes in case the
> hosting company ever decides to change the settings?
Yup! Just because it's on now doesn't mean it always will be. Never
depend on any setting that you don't control if you can avoid so
depending.
--
Windows gives you a nice view of clouds so you can't see any potentially
useful boot time messages.
-- Bill Hay in the Monastery
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176388 is a reply to message #176386] |
Fri, 30 December 2011 04:32 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
On Thu, 29 Dec 2011 17:53:09 -0600, "Peter H. Coffin"
<hellsop(at)ninehells(dot)com> wrote:
> On Thu, 29 Dec 2011 15:55:10 -0500, Michael Joel wrote:
>> I do not have control of my server (shared server).
>>
>> echo get_magic_quotes_gpc(); returns True.
>> Should I still be cautious and use addslashes/stripslashes in case the
>> hosting company ever decides to change the settings?
>
> Yup! Just because it's on now doesn't mean it always will be. Never
> depend on any setting that you don't control if you can avoid so
> depending.
I just read that magic quotes automatically adds and * removes *
slashes.
So then my questions is, why test for magic quotes - why not just use
addslashes/stripslashes? At worste it appears to be just reprocessing
what has just been done for you.
The server has it turned on and yet if I simply add/strip without
testing it still appears the same way.
Mike
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176390 is a reply to message #176378] |
Fri, 30 December 2011 09:26 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 29/12/2011 21:55, Michael Joel escribió/wrote:
> I do not have control of my server (shared server).
>
> echo get_magic_quotes_gpc(); returns True.
> Should I still be cautious and use addslashes/stripslashes in case the
> hosting company ever decides to change the settings?
I'm not fully sure of what you want to know, but I personally find that
magic quotes makes coding more difficult and annoying. I normally do the
following:
1. Change settings to disable all these annoying "magic" features: magic
quotes, register globals... This involves either .htaccess or a custom
php.ini file, depending on the server API. (Many of these features
cannot be changed in PHP code because they are already in affect when
the script starts executing.)
2. Add a few verifications to my bootstrap file (the site's settings
file) so I'm notified when settings are wrong.
3. Code normally.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176393 is a reply to message #176388] |
Fri, 30 December 2011 11:38 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/30/2011 5:32 AM, Michael Joel wrote:
> On Thu, 29 Dec 2011 17:53:09 -0600, "Peter H. Coffin"
> <hellsop(at)ninehells(dot)com> wrote:
>
>> On Thu, 29 Dec 2011 15:55:10 -0500, Michael Joel wrote:
>>> I do not have control of my server (shared server).
>>>
>>> echo get_magic_quotes_gpc(); returns True.
>>> Should I still be cautious and use addslashes/stripslashes in case the
>>> hosting company ever decides to change the settings?
>>
>> Yup! Just because it's on now doesn't mean it always will be. Never
>> depend on any setting that you don't control if you can avoid so
>> depending.
>
> I just read that magic quotes automatically adds and * removes *
> slashes.
I think you misunderstood.
It is wrong.
The gpc in magic_quotes_gpc means $_GET / $_POST / $_COOKIE.
Values originating from one of those will be escaped by a backslash.
Where do you think there are magically removed?
Regards,
Erwin Moller
>
> So then my questions is, why test for magic quotes - why not just use
> addslashes/stripslashes? At worste it appears to be just reprocessing
> what has just been done for you.
>
> The server has it turned on and yet if I simply add/strip without
> testing it still appears the same way.
>
> Mike
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176394 is a reply to message #176388] |
Fri, 30 December 2011 12:18 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Michael Joel)
> So then my questions is, why test for magic quotes - why not just use
> addslashes/stripslashes? At worste it appears to be just reprocessing
> what has just been done for you.
Magic quotes are not secure and will be completely removed in the near
future. Even addslashes/stripslashes are not secure, because they don't
escape all necessary characters for database input.
So the general rule is: Test for magic quotes if you can't disable them,
remove them if necessary with stripslashes(), then apply the appropriate
escaping functions wherever necessary (e.g. mysql_real_escape_string()).
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176395 is a reply to message #176378] |
Fri, 30 December 2011 13:42 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/29/2011 9:55 PM, Michael Joel wrote:
> I do not have control of my server (shared server).
>
> echo get_magic_quotes_gpc(); returns True.
> Should I still be cautious and use addslashes/stripslashes in case the
> hosting company ever decides to change the settings?
>
> Thanks
> Mike
Hi Mike,
To sum up all the responses so far:
1) Avoid all use of magic_quotes in your code. Do not rely on it.
2) If you want your programs to be prepared for magic_quotes, as in
older shared hosting environments like yours, write a small function to
wrap the test in, like:
function getRawGPCValue($someGPCStr){
if (get_magic_quotes_gpc() === 1){
return stripslashes($someGPCStr);
} else {
return $someGPCStr;
}
}
And then when you need a value from $_POST, simply do:
$firstName = getRawGPCValue($_POST("firstname"));
You might want to use a shorter functionname. ;-)
3) When you need to use the value from sources like GPC, simply do the
right thing with the *raw* data.
For example:
a) When you expect an integer, don't mind the escaping, simply cast it
to integer:
$userid = (int)$_POST["userid"];
(You might want to add additional checks of course, like rnage of the
number, if $_POST["userid"] is set at all, etc.)
b) When you want to output it to HTML:
$firstName = getRawGPCValue($_POST("firstname"));
echo htmlentities($firstName);
For more details like charset/encoding read here:
http://nl3.php.net/manual/en/function.htmlentities.php
c) When you want to insert characterdata into your database:
Use the right escape function suitable for your database, or use
something like PDO.
eg: mysql_real_escape_string() for mysql
pg_escape_literal() for Postgres.
etc.
d) When using in an URL, url encode the raw data.
etc. etc. etc.
Bottomline: Make sure you have the raw (real) data, and use the
appropriate approach before using.
There is no "magic" solution that solves all possible situations,
despite names like "magic_quotes".
Escaping of strings works differently for URLs, HTML, databaseX, databaseY,
Tip:
When the encoding of some string is different than for example the
receiving database, have a look at iconv. It saved me a few headaches.
http://nl3.php.net/manual/en/function.iconv.php
Good luck!
regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176396 is a reply to message #176393] |
Fri, 30 December 2011 14:52 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
On Fri, 30 Dec 2011 12:38:01 +0100, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)com> wrote:
> On 12/30/2011 5:32 AM, Michael Joel wrote:
>> On Thu, 29 Dec 2011 17:53:09 -0600, "Peter H. Coffin"
>> <hellsop(at)ninehells(dot)com> wrote:
>> .....SNIP...............................
> Where do you think there are magically removed?
>
>> .....SNIP...............................
from the book PHP and MYSQL: Web Development (Welling and Thomson).
I tested this and it is true.
slashes are added and removed automatically.
I "imagine" when the vairiables post they are added then when you
access the vars they are removed. In any case my tests to see shows
the book is correct.
As a later poster says though all this is being deprecated so it will
become useless.
Thanks
Mike
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176397 is a reply to message #176395] |
Fri, 30 December 2011 14:52 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
On Fri, 30 Dec 2011 14:42:43 +0100, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)com> wrote:
> On 12/29/2011 9:55 PM, Michael Joel wrote:
>> I do not have control of my server (shared server).
>>
>> echo get_magic_quotes_gpc(); returns True.
>> Should I still be cautious and use addslashes/stripslashes in case the
>> hosting company ever decides to change the settings?
>>
>> Thanks
>> Mike
>
> Hi Mike,
>
> To sum up all the responses so far:
> 1) Avoid all use of magic_quotes in your code. Do not rely on it.
> 2) If you want your programs to be prepared for magic_quotes, as in
> older shared hosting environments like yours, write a small function to
> wrap the test in, like:
>
> function getRawGPCValue($someGPCStr){
> if (get_magic_quotes_gpc() === 1){
> return stripslashes($someGPCStr);
> } else {
> return $someGPCStr;
> }
> }
>
> And then when you need a value from $_POST, simply do:
> $firstName = getRawGPCValue($_POST("firstname"));
>
> You might want to use a shorter functionname. ;-)
>
>
> 3) When you need to use the value from sources like GPC, simply do the
> right thing with the *raw* data.
>
> For example:
> a) When you expect an integer, don't mind the escaping, simply cast it
> to integer:
> $userid = (int)$_POST["userid"];
> (You might want to add additional checks of course, like rnage of the
> number, if $_POST["userid"] is set at all, etc.)
>
> b) When you want to output it to HTML:
> $firstName = getRawGPCValue($_POST("firstname"));
> echo htmlentities($firstName);
> For more details like charset/encoding read here:
> http://nl3.php.net/manual/en/function.htmlentities.php
>
> c) When you want to insert characterdata into your database:
> Use the right escape function suitable for your database, or use
> something like PDO.
> eg: mysql_real_escape_string() for mysql
> pg_escape_literal() for Postgres.
> etc.
>
> d) When using in an URL, url encode the raw data.
>
>
> etc. etc. etc.
>
>
> Bottomline: Make sure you have the raw (real) data, and use the
> appropriate approach before using.
> There is no "magic" solution that solves all possible situations,
> despite names like "magic_quotes".
> Escaping of strings works differently for URLs, HTML, databaseX, databaseY,
>
> Tip:
> When the encoding of some string is different than for example the
> receiving database, have a look at iconv. It saved me a few headaches.
> http://nl3.php.net/manual/en/function.iconv.php
>
> Good luck!
>
> regards,
> Erwin Moller
Thanks - and thanks all.
This is a lot of information. I plan to go back and adjust the code to
comply better.
Thanks again
Mike
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176405 is a reply to message #176396] |
Mon, 02 January 2012 14:02 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/30/2011 3:52 PM, Michael Joel wrote:
> On Fri, 30 Dec 2011 12:38:01 +0100, Erwin Moller
> <Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)com> wrote:
>
>> On 12/30/2011 5:32 AM, Michael Joel wrote:
>>> On Thu, 29 Dec 2011 17:53:09 -0600, "Peter H. Coffin"
>>> <hellsop(at)ninehells(dot)com> wrote:
>>> .....SNIP...............................
>> Where do you think there are magically removed?
>>
>>> .....SNIP...............................
>
>
> from the book PHP and MYSQL: Web Development (Welling and Thomson).
> I tested this and it is true.
> slashes are added and removed automatically.
>
> I "imagine" when the vairiables post they are added then when you
> access the vars they are removed. In any case my tests to see shows
> the book is correct.
>
> As a later poster says though all this is being deprecated so it will
> become useless.
>
> Thanks
> Mike
Hi Mike,
I don't know this book, but is seems it did a very poor job explaining
the matter. I'll try to make it clearer.
This is what happens when you have magic_quotes on:
1) Your webserver presents a document with a form to a client.
Lets say it is named signup.html and it contains, amongst others, the
following:
<form action="signup_process.php" Method="post">
Your name: <input type="text" name="firstname" value="">
<input type="submit" value="Post it">
</form>
2) Somebody types in the above form the following:
Joe "hi' Jones
and sends it.
3) At the webserver signup_process.php is invoked.
The environment of PHP contains values in the superglobal $_POST array.
Here (and only here) magic_quotes comes into play.
$_POST["firstname"] contains *Joe "hi' Jones* when magic quotes are off.
$_POST["firstname"] contains *Joe \"hi\' Jones* when magic quotes are on.
(Outer ** added by me, they are not in the variable.)
The only reason those magic quotes were invented is because of the
following: If a lazy/sloppy programmer wanted to use these variables to
insert them into a database, (s)he would do the following:
$SQL =
"INSERT INTO tblusers (firstname) VALUES ('".$_POST["firstname"]."');";
And then execute that statement against some database:
somedb_execute($SQL);
That approach would work fine if the data didn't contain " or ' (and
other naughty characters. Naughty depends on the database in question).
So simply using the values from $_POST would make the receiving script
vulnerable to SQL injection.
A better way (but still not 100% safe) would be to first escape the
received string, like this:
$saferFirstName = addslashes($_POST["firstname"]);
That is why magic_quotes was "invented": It does this addslashes()
automatically for all data that is put into $_GET and $_POST and
$_COOKIE, in case you forget.
So the adding of slashes solves a few problems:
a) It makes it possible to use the character ' or " inside the query.
Note that ' and " are often used in SQL to delimit a string of
characters (for the database field types: text, char, etc).
b) It makes simple SQL injection impossible (Note the word 'simple').
When you read back from the database with the above example like:
SELECT firstname from tblusers;
You will neatly receive *Joe "hi' Jones* as is intended. The slashes are
gone because they were only used to tell the database that the next
character is escaped.
This behavior is probably the reason your book claims that the slashes
are removed, which isn't exactly correct. They were actually never
inserted into the database and only had their use to tell the database
to take the next character literally.
But it was a bad idea for several reasons. To name a few:
a) Escaping only ' and " isn't enough. Different databases have other
character(sequence)s that allow for unintended action when executed with
only addslashes().
b) It gives newbies a false sense of security. They might think
something like "I have those magic quotes on, so my application is safe
for SQL injection.", which it isn't.
Hope that helped. :-)
Make sure you understand the issues involved, or you will be bitten in
the back later.
It really helped me to understand it all by hacking my own applications.
It is worth your time, and many hacks and cracks you can read about on
the net make sense when you do it yourself.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176413 is a reply to message #176412] |
Thu, 05 January 2012 13:08 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/4/2012 3:55 PM, Arno Welzel wrote:
> Michael Joel, 2011-12-29 21:55:
>
>> I do not have control of my server (shared server).
>>
>> echo get_magic_quotes_gpc(); returns True.
>> Should I still be cautious and use addslashes/stripslashes in case the
>> hosting company ever decides to change the settings?
>
> I assume magic quotes to be disabled and in the past i used the
> following code fragment to be safe:
>
> <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>
>
Hi Arnold,
That is a lot of overhead on each request.
It loops over all superglobals and calls stripslashes on each of them
(in case magic_quotes is on).
You also do this for $_ENV and $_SERVER which seems strange to me
because magic_quotes only affects cookie/post/get.
magic_quotes_gpc Affects HTTP Request data (GET, POST, and COOKIE).
source: http://nl3.php.net/manual/en/security.magicquotes.what.php
And $_REQUEST should be avoided anyway in all situation (in my humble
opinion) for various reasons. But if you use it, it should indeed be
added to your list in your approach.
Regards,
Erwin Moller
Your code:
===========================================
ini_set('magic_quotes_runtime', 0);
if(get_magic_quotes_gpc())
{
$superglobals=array(
"_REQUEST",
"_GET",
"_POST",
"_COOKIE",
"_ENV",
"_SERVER");
foreach($superglobals as $globalname)
{
foreach($GLOBALS[$globalname] as $name => $value)
{
if(!is_array($value))
{
$GLOBALS[$globalname][$name] = stripslashes($value);
}
}
}
unset($superglobals);
}
===========================================
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176414 is a reply to message #176413] |
Thu, 05 January 2012 13:22 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Erwin Moller, 2012-01-05 14:08:
> On 1/4/2012 3:55 PM, Arno Welzel wrote:
>> Michael Joel, 2011-12-29 21:55:
>>
>>> I do not have control of my server (shared server).
>>>
>>> echo get_magic_quotes_gpc(); returns True.
>>> Should I still be cautious and use addslashes/stripslashes in case the
>>> hosting company ever decides to change the settings?
>>
>> I assume magic quotes to be disabled and in the past i used the
>> following code fragment to be safe:
>>
>> <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>>
>>
>
> Hi Arnold,
Just Arno - not Arnold ;-)
> That is a lot of overhead on each request.
I know - and this is only meant to be a workaround for existing code
which can not be easily adopted to handle Magic Quotes and the PHP
configuration can not be changed.
> And $_REQUEST should be avoided anyway in all situation (in my humble
> opinion) for various reasons. But if you use it, it should indeed be
> added to your list in your approach.
I'm not sure, if it's enough to modify $_GET, $_POST etc. if further
parts of a script use $_REQUEST - therefore i added $_REQUEST to be sure.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176415 is a reply to message #176414] |
Thu, 05 January 2012 13:36 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Arno Welzel wrote:
> Erwin Moller, 2012-01-05 14:08:
>
>> On 1/4/2012 3:55 PM, Arno Welzel wrote:
>>> Michael Joel, 2011-12-29 21:55:
>>>
>>>> I do not have control of my server (shared server).
>>>>
>>>> echo get_magic_quotes_gpc(); returns True.
>>>> Should I still be cautious and use addslashes/stripslashes in case the
>>>> hosting company ever decides to change the settings?
>>> I assume magic quotes to be disabled and in the past i used the
>>> following code fragment to be safe:
>>>
>>> <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>>>
>>>
>> Hi Arnold,
>
> Just Arno - not Arnold ;-)
>
>
>> That is a lot of overhead on each request.
>
> I know - and this is only meant to be a workaround for existing code
> which can not be easily adopted to handle Magic Quotes and the PHP
> configuration can not be changed.
>
>> And $_REQUEST should be avoided anyway in all situation (in my humble
>> opinion) for various reasons. But if you use it, it should indeed be
>> added to your list in your approach.
>
> I'm not sure, if it's enough to modify $_GET, $_POST etc. if further
> parts of a script use $_REQUEST - therefore i added $_REQUEST to be sure.
>
>
I am interested in this, because in general I leave magic quotes on
because some old code relies on it on some of my sites..
Is this comment still true? - its from the PHP manual
"I have discovered that my host doesn't like either of the following
directives in the .htaccess file:
php_flag magic_quotes_gpc Off
php_value magic_quotes_gpc Off
However, there is another way to disable this setting even if you don't
have access to the server configuration - you can put a php.ini file in
the directory where your scripts are with the directive:
magic_quotes_gpc = Off
However, these does not propogate unlike .htaccess rules, so if you
launch from a sub-directory, you need the php.ini file in each directory
you have as script entry points."
If so it, gives another option to override server defaults.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176416 is a reply to message #176414] |
Thu, 05 January 2012 13:39 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/5/2012 2:22 PM, Arno Welzel wrote:
> Erwin Moller, 2012-01-05 14:08:
>
>> On 1/4/2012 3:55 PM, Arno Welzel wrote:
>>> Michael Joel, 2011-12-29 21:55:
>>>
>>>> I do not have control of my server (shared server).
>>>>
>>>> echo get_magic_quotes_gpc(); returns True.
>>>> Should I still be cautious and use addslashes/stripslashes in case the
>>>> hosting company ever decides to change the settings?
>>>
>>> I assume magic quotes to be disabled and in the past i used the
>>> following code fragment to be safe:
>>>
>>> <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>>>
>>>
>>
>> Hi Arnold,
>
> Just Arno - not Arnold ;-)
Excuse me, Arno. :-)
I say a lot of Arnold lately since I go to sport school for the first
time in my life. I do this with a friend (who is also a fat programmer
like me) and we call each other Arnold when we are training muscles and
stuff. ;-)
Slip of the tongue, my bad.
>
>> That is a lot of overhead on each request.
>
> I know - and this is only meant to be a workaround for existing code
> which can not be easily adopted to handle Magic Quotes and the PHP
> configuration can not be changed.
>
>> And $_REQUEST should be avoided anyway in all situation (in my humble
>> opinion) for various reasons. But if you use it, it should indeed be
>> added to your list in your approach.
>
> I'm not sure, if it's enough to modify $_GET, $_POST etc. if further
> parts of a script use $_REQUEST - therefore i added $_REQUEST to be sure.
>
I wondered the same thing, actually.
So here is a little test:
<?php
if (isset($_GET["n"])){
$nget = $_GET["n"];
$nrequest = $_REQUEST["n"];
echo "Before:<br>\$nget=$nget<br>\$nrequest=$nrequest<br>";
$_GET["n"] = "something else";
$nget = $_GET["n"];
$nrequest = $_REQUEST["n"];
echo "After:<br>\$nget=$nget<br>\$nrequest=$nrequest<br>";
} else {
echo "use test.php?n=whatever in the url.";
}
?>
When I feed that prog "hi, like this":
http://localhost/test.php?n=hi
It responds with:
Before:
$nget=hi
$nrequest=hi
After:
$nget=something else
$nrequest=hi
Conclusion? $_REQUEST is filled for real, and it doesn't fetch the
information afterwards from GPC which was indeed also possible.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176417 is a reply to message #176415] |
Thu, 05 January 2012 14:20 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/5/2012 2:36 PM, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Erwin Moller, 2012-01-05 14:08:
>>
>>> On 1/4/2012 3:55 PM, Arno Welzel wrote:
>>>> Michael Joel, 2011-12-29 21:55:
>>>>
>>>> > I do not have control of my server (shared server).
>>>> >
>>>> > echo get_magic_quotes_gpc(); returns True.
>>>> > Should I still be cautious and use addslashes/stripslashes in case the
>>>> > hosting company ever decides to change the settings?
>>>> I assume magic quotes to be disabled and in the past i used the
>>>> following code fragment to be safe:
>>>>
>>>> <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>>>>
>>>>
>>> Hi Arnold,
>>
>> Just Arno - not Arnold ;-)
>>
>>
>>> That is a lot of overhead on each request.
>>
>> I know - and this is only meant to be a workaround for existing code
>> which can not be easily adopted to handle Magic Quotes and the PHP
>> configuration can not be changed.
>>
>>> And $_REQUEST should be avoided anyway in all situation (in my humble
>>> opinion) for various reasons. But if you use it, it should indeed be
>>> added to your list in your approach.
>>
>> I'm not sure, if it's enough to modify $_GET, $_POST etc. if further
>> parts of a script use $_REQUEST - therefore i added $_REQUEST to be sure.
>>
>>
> I am interested in this, because in general I leave magic quotes on
> because some old code relies on it on some of my sites..
Hi NP,
I feel your pain. I am in the same situation. :-(
(I have an old PHP4.3 machine under my control with magic_quotes on.)
>
>
> Is this comment still true? - its from the PHP manual
>
> "I have discovered that my host doesn't like either of the following
> directives in the .htaccess file:
>
> php_flag magic_quotes_gpc Off
> php_value magic_quotes_gpc Off
>
> However, there is another way to disable this setting even if you don't
> have access to the server configuration - you can put a php.ini file in
> the directory where your scripts are with the directive:
>
> magic_quotes_gpc = Off
>
> However, these does not propogate unlike .htaccess rules, so if you
> launch from a sub-directory, you need the php.ini file in each directory
> you have as script entry points."
>
>
> If so it, gives another option to override server defaults.
I wouldn't bet on that trick to work everywhere.
It seems to me that depends on the way PHP and/or Apache is set up.
Much safer is simply wrap a simple function around $_POST["whatever"]
that tests for the real situation.
Or use Arno's trick, which is a little heavier on the server because it
strips more than needed.
The advantage of Arno's approach is of course that you don't have to
adjust existing code: you can simply enforce magic_quotes or shut them down.
I do prefer a wrapperfunction. That way you have no server dependencies
in your PHP code.
Well, at least not for magic_quotes that is. ;-)
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176418 is a reply to message #176417] |
Thu, 05 January 2012 15:49 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 1/5/2012 2:36 PM, The Natural Philosopher wrote:
>> Arno Welzel wrote:
>>> Erwin Moller, 2012-01-05 14:08:
>>>
>>>> On 1/4/2012 3:55 PM, Arno Welzel wrote:
>>>> > Michael Joel, 2011-12-29 21:55:
>>>> >
>>>> >> I do not have control of my server (shared server).
>>>> >>
>>>> >> echo get_magic_quotes_gpc(); returns True.
>>>> >> Should I still be cautious and use addslashes/stripslashes in case
>>>> >> the
>>>> >> hosting company ever decides to change the settings?
>>>> > I assume magic quotes to be disabled and in the past i used the
>>>> > following code fragment to be safe:
>>>> >
>>>> > <http://arnowelzel.de/wiki/en/web/php_magicquotes>
>>>> >
>>>> >
>>>> Hi Arnold,
>>>
>>> Just Arno - not Arnold ;-)
>>>
>>>
>>>> That is a lot of overhead on each request.
>>>
>>> I know - and this is only meant to be a workaround for existing code
>>> which can not be easily adopted to handle Magic Quotes and the PHP
>>> configuration can not be changed.
>>>
>>>> And $_REQUEST should be avoided anyway in all situation (in my humble
>>>> opinion) for various reasons. But if you use it, it should indeed be
>>>> added to your list in your approach.
>>>
>>> I'm not sure, if it's enough to modify $_GET, $_POST etc. if further
>>> parts of a script use $_REQUEST - therefore i added $_REQUEST to be
>>> sure.
>>>
>>>
>> I am interested in this, because in general I leave magic quotes on
>> because some old code relies on it on some of my sites..
>
> Hi NP,
>
> I feel your pain. I am in the same situation. :-(
> (I have an old PHP4.3 machine under my control with magic_quotes on.)
>
>
>>
>>
>> Is this comment still true? - its from the PHP manual
>>
>> "I have discovered that my host doesn't like either of the following
>> directives in the .htaccess file:
>>
>> php_flag magic_quotes_gpc Off
>> php_value magic_quotes_gpc Off
>>
>> However, there is another way to disable this setting even if you don't
>> have access to the server configuration - you can put a php.ini file in
>> the directory where your scripts are with the directive:
>>
>> magic_quotes_gpc = Off
>>
>> However, these does not propogate unlike .htaccess rules, so if you
>> launch from a sub-directory, you need the php.ini file in each directory
>> you have as script entry points."
>>
>>
>> If so it, gives another option to override server defaults.
>
> I wouldn't bet on that trick to work everywhere.
> It seems to me that depends on the way PHP and/or Apache is set up.
>
well that on my new cheap virtual server is entirely UP TO ME!!
I cannot believe how little it costs, either. <$200 a year (about £160
uk IIRC)
I am limited on RAM and disk space, and total byte transfers but CPU
power is - massive. As is network speed.
Its all RAIDED..
And a quick rsync backs it up on the server here every night..in case.
Best of all with my admin center here on a fixed IP address, I can set
the firewall to let ME have unlimited access to it.
I actually NFS mount the web sites when I am working on them and edit
the files directly if I feel lucky. No more FTP uploads.
The cherry on the cake was putting a pass through for its IP address
into my admin network here and setting up a print queue that prints
directly to the printer on my desk!
Apart from a slight speed issue saving files, it's like it was a machine
here in the office.
(except when the power went out last night, it stayed up)
If you have more than a few websites its well worth doing this I feel.
> Much safer is simply wrap a simple function around $_POST["whatever"]
> that tests for the real situation.
> Or use Arno's trick, which is a little heavier on the server because it
> strips more than needed.
> The advantage of Arno's approach is of course that you don't have to
> adjust existing code: you can simply enforce magic_quotes or shut them
> down.
>
> I do prefer a wrapperfunction. That way you have no server dependencies
> in your PHP code.
> Well, at least not for magic_quotes that is. ;-)
>
> Regards,
> Erwin Moller
>
>
IF I was stick with a server setup that meant I had no other choice, I
would.
My situation is different however. I am looking for the simplest way to
make it a per site option, and not a global one.
Given its my server to do what I like with..
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176419 is a reply to message #176413] |
Thu, 05 January 2012 23:28 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 05.01.2012 14:08, schrieb Erwin Moller:
>
> And $_REQUEST should be avoided anyway in all situation (in my
> humble opinion) for various reasons. But if you use it, it should
> indeed be added to your list in your approach.
>
> Regards,
> Erwin Moller
For me $_REQUEST is quite handy. All my functions reading user
input use this. So they work equally well on different requests.
But then I have to mention my setup with a sort of call
dispatcher: the called function is looked up in a list taking
into account $_SERVER['REQUEST_METHOD'].
All user input must be verified, no matter if it's in $_GET,
$_POST, $_COOKIE or $_REQUEST for that matter - they can all be
faked!
Do not think that only your forms will be sent to your program.
/Str.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176420 is a reply to message #176419] |
Fri, 06 January 2012 00:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/5/2012 6:28 PM, M. Strobel wrote:
> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>
>> And $_REQUEST should be avoided anyway in all situation (in my
>> humble opinion) for various reasons. But if you use it, it should
>> indeed be added to your list in your approach.
>>
>> Regards,
>> Erwin Moller
>
> For me $_REQUEST is quite handy. All my functions reading user
> input use this. So they work equally well on different requests.
>
> But then I have to mention my setup with a sort of call
> dispatcher: the called function is looked up in a list taking
> into account $_SERVER['REQUEST_METHOD'].
>
> All user input must be verified, no matter if it's in $_GET,
> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
> faked!
>
> Do not think that only your forms will be sent to your program.
>
> /Str.
$REQUESTS is quite dangerous. You never know whether it comes from
$_GET, $_POST or $_COOKIE, for instance.
A hacker can easily manipulate things like $_COOKIE to put whatever he
wants in them. Rather, you should use $_GET, $_POST and $_COOKIE, as
appropriate. Additionally, what you actually get depends on the
request_order option in the php.ini file, and can change - potentially
breaking your code.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176421 is a reply to message #176419] |
Fri, 06 January 2012 10:07 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 12:28 AM, M. Strobel wrote:
> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>
>> And $_REQUEST should be avoided anyway in all situation (in my
>> humble opinion) for various reasons. But if you use it, it should
>> indeed be added to your list in your approach.
>>
>> Regards,
>> Erwin Moller
>
> For me $_REQUEST is quite handy. All my functions reading user
> input use this. So they work equally well on different requests.
Hi Strobel,
And why do you prefer $_REQUEST over using the exact superglobal?
You do know where the information is supposed to come from.
>
> But then I have to mention my setup with a sort of call
> dispatcher: the called function is looked up in a list taking
> into account $_SERVER['REQUEST_METHOD'].
That explanation makes no sense to me without any more context.
Are you saying you are limiting access to certain function by checking
the used $_SERVER['REQUEST_METHOD']?
If so, that won't help at all, since anybody could still use the "right"
REQUEST_METHOD and manipulate the contents of GPC at the same time.
>
> All user input must be verified, no matter if it's in $_GET,
> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
> faked!
Of course.
But how does that relate to using $_REQUEST over the exact superglobal?
>
> Do not think that only your forms will be sent to your program.
>
> /Str.
I still see no reason at all to use $_REQUEST. It strikes me as lazy and
dangerous.
Of course you can program right and safe using $_REQUEST only, but it is
harder. On all occasion you have to wonder if the information you get
presented came from the place you expected it to come from.
Ans since there is no trade-off (no advantage in using $_REQUEST over
the exact superglobal) I don't see why you use it.
Often people who use it (in my experience) use $_REQUEST because they
never bothered to understand how and what information is send around.
Hence they had a poor understanding of what they are doing.
I am not saying you don't understand. I just cannot think of any valid
reason to use $_REQUEST.
In my opinion $_REQUEST is a design mistake by the PHP developers, just
like magic_quotes. :-)
If you think I am wrong about that, please tell me why.
I had this discussion a few years back too, but the guy turned out to be
a troll (and silly me took the bait!), so that turned out to be a dead end.
I am curious what the advantages or $_REQUEST are in your opinion.
In a few exceptional cases where I do expect the info coming from POST
or GET and cannot tell which one, I simply use something like:
$thing = (
(isset($_GET["thingy"]))?$_GET["thingy"]:
(isset($_POST["thingy"])?$_POST["thingy"]:"not set")
);
which is a bit awkward.
But since I almost always know where my data comes from, I don't mind
such a contraption once in a while. :-)
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176422 is a reply to message #176420] |
Fri, 06 January 2012 10:16 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 1:36 AM, Jerry Stuckle wrote:
> On 1/5/2012 6:28 PM, M. Strobel wrote:
>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>
>>> And $_REQUEST should be avoided anyway in all situation (in my
>>> humble opinion) for various reasons. But if you use it, it should
>>> indeed be added to your list in your approach.
>>>
>>> Regards,
>>> Erwin Moller
>>
>> For me $_REQUEST is quite handy. All my functions reading user
>> input use this. So they work equally well on different requests.
>>
>> But then I have to mention my setup with a sort of call
>> dispatcher: the called function is looked up in a list taking
>> into account $_SERVER['REQUEST_METHOD'].
>>
>> All user input must be verified, no matter if it's in $_GET,
>> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
>> faked!
>>
>> Do not think that only your forms will be sent to your program.
>>
>> /Str.
>
> $REQUESTS is quite dangerous. You never know whether it comes from
> $_GET, $_POST or $_COOKIE, for instance.
>
> A hacker can easily manipulate things like $_COOKIE to put whatever he
> wants in them. Rather, you should use $_GET, $_POST and $_COOKIE, as
> appropriate. Additionally, what you actually get depends on the
> request_order option in the php.ini file, and can change - potentially
> breaking your code.
>
Yes exactly.
Jerry, if memory serves me well, I had a discussion concerning $_REQUEST
a few years ago with a guy. He became increasingly annoying, until you
saved me from a headache by telling me I was taking the troll bait. ;-)
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176423 is a reply to message #176420] |
Fri, 06 January 2012 11:05 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle schrieb:
> $REQUESTS is quite dangerous. You never know whether it comes from
> $_GET, $_POST or $_COOKIE, for instance.
True, you don't know. But does it matter? The only problem I see is that
the order of precedence of the three input sources depends on the PHP
configuration, but aside from that, the script is given a "foo=bar" and
a hacker could always send that via any of GET, POST or COOKIE. So my
script should not be dependent on that. I find it rather convenient to
be able to send commands/arguments to my script via any of the three
methods.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176424 is a reply to message #176423] |
Fri, 06 January 2012 13:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> $REQUESTS is quite dangerous. You never know whether it comes from
>> $_GET, $_POST or $_COOKIE, for instance.
>
> True, you don't know. But does it matter? The only problem I see is that
> the order of precedence of the three input sources depends on the PHP
> configuration, but aside from that, the script is given a "foo=bar" and
> a hacker could always send that via any of GET, POST or COOKIE. So my
> script should not be dependent on that. I find it rather convenient to
> be able to send commands/arguments to my script via any of the three
> methods.
>
> Greetings,
> Thomas
>
No, it doesn't matter if you aren't concerned about security.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176425 is a reply to message #176420] |
Fri, 06 January 2012 16:41 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 01:36, schrieb Jerry Stuckle:
> On 1/5/2012 6:28 PM, M. Strobel wrote:
>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>
------cut
>
> $REQUESTS is quite dangerous. You never know whether it comes
> from $_GET, $_POST or $_COOKIE, for instance.
Why do you need to know exactly if the data is from GET or POST?
Does your program use POST urls with variables in the url?
If yes, did you not take care to have different variable names?
I know one thing: the data comes from the user.
> A hacker can easily manipulate things like $_COOKIE to put
> whatever he wants in them. Rather, you should use $_GET, $_POST
> and $_COOKIE, as appropriate. Additionally, what you actually
> get depends on the request_order option in the php.ini file, and
> can change - potentially breaking your code.
>
Why mention cookie here? He can manipulate everything.
I taught an interface programmer how to test my forms with curl,
see here http://curl.haxx.se/docs/manpage.html especially the
--get and --form options.
$_REQUEST is not more dangerous than programming in PHP. q.e.d.
/Str.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176426 is a reply to message #176421] |
Fri, 06 January 2012 17:05 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 11:07, schrieb Erwin Moller:
> On 1/6/2012 12:28 AM, M. Strobel wrote:
>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>
-----------cut on various places
> Hi Strobel,
>
> And why do you prefer $_REQUEST over using the exact superglobal?
> You do know where the information is supposed to come from.
>
Yes I know that exactly. But why care? When I expect data I do
function getIntFromForm($key, $def=null) {
if (isset($_REQUEST[$key])) {
if ($a = sscanf($_REQUEST[$key], '%d')) { // unsigned
$def = $a[0];
} else {
# keine Zahl im Wert $key / no number
}
} else {
# key nicht gefunden / no key
}
return $def;
}
>
>>
>> But then I have to mention my setup with a sort of call
>> dispatcher: the called function is looked up in a list taking
>> into account $_SERVER['REQUEST_METHOD'].
>
> That explanation makes no sense to me without any more context.
> Are you saying you are limiting access to certain function by
> checking the used $_SERVER['REQUEST_METHOD']?
> If so, that won't help at all, since anybody could still use the
> "right" REQUEST_METHOD and manipulate the contents of GPC at the
> same time.
This is correct, it is not a real protection, but part of the
request processing. And the correct request processing takes care
to only read in and verify expected data.
>>
>> All user input must be verified, no matter if it's in $_GET,
>> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
>> faked!
>
> Of course.
> But how does that relate to using $_REQUEST over the exact
> superglobal?
if (is-a-post-operation AND data-expected)
read post data;
elseif (is-a-get-operation AND data-expected)
read get data;
What for? Just do
if (data-expected) read request data.
> If you think I am wrong about that, please tell me why.
> I had this discussion a few years back too, but the guy turned
> out to be a troll (and silly me took the bait!), so that turned
> out to be a dead end.
Always check data on input :-)
>
> Regards,
> Erwin Moller
>
/Str.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176427 is a reply to message #176424] |
Fri, 06 January 2012 17:18 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 14:32, schrieb Jerry Stuckle:
> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>> Jerry Stuckle schrieb:
>>
>>> $REQUESTS is quite dangerous. You never know whether it comes
>>> from
>>> $_GET, $_POST or $_COOKIE, for instance.
>>
>> True, you don't know. But does it matter? The only problem I
>> see is that
>> the order of precedence of the three input sources depends on
>> the PHP
>> configuration, but aside from that, the script is given a
>> "foo=bar" and
>> a hacker could always send that via any of GET, POST or COOKIE.
>> So my
>> script should not be dependent on that. I find it rather
>> convenient to
>> be able to send commands/arguments to my script via any of the
>> three
>> methods.
>>
>> Greetings,
>> Thomas
>>
>
> No, it doesn't matter if you aren't concerned about security.
>
I think programming leaves enough room for everybody to use $_GET
and $_POST to their liking, but
$_REQUEST is no more dangerous than one of GPC.
There are some programming mantras you have to keep on saying,
this is not one of it.
/Str
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176428 is a reply to message #176427] |
Fri, 06 January 2012 18:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 12:18 PM, M. Strobel wrote:
> Am 06.01.2012 14:32, schrieb Jerry Stuckle:
>> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>>
>>>> $REQUESTS is quite dangerous. You never know whether it comes
>>>> from
>>>> $_GET, $_POST or $_COOKIE, for instance.
>>>
>>> True, you don't know. But does it matter? The only problem I
>>> see is that
>>> the order of precedence of the three input sources depends on
>>> the PHP
>>> configuration, but aside from that, the script is given a
>>> "foo=bar" and
>>> a hacker could always send that via any of GET, POST or COOKIE.
>>> So my
>>> script should not be dependent on that. I find it rather
>>> convenient to
>>> be able to send commands/arguments to my script via any of the
>>> three
>>> methods.
>>>
>>> Greetings,
>>> Thomas
>>>
>>
>> No, it doesn't matter if you aren't concerned about security.
>>
>
> I think programming leaves enough room for everybody to use $_GET
> and $_POST to their liking, but
>
> $_REQUEST is no more dangerous than one of GPC.
>
> There are some programming mantras you have to keep on saying,
> this is not one of it.
>
> /Str
This is one which only those unconcerned about security use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176429 is a reply to message #176425] |
Fri, 06 January 2012 18:05 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 11:41 AM, M. Strobel wrote:
> Am 06.01.2012 01:36, schrieb Jerry Stuckle:
>> On 1/5/2012 6:28 PM, M. Strobel wrote:
>>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>>
> ------cut
>>
>> $REQUESTS is quite dangerous. You never know whether it comes
>> from $_GET, $_POST or $_COOKIE, for instance.
>
> Why do you need to know exactly if the data is from GET or POST?
> Does your program use POST urls with variables in the url?
>
> If yes, did you not take care to have different variable names?
>
> I know one thing: the data comes from the user.
>
>> A hacker can easily manipulate things like $_COOKIE to put
>> whatever he wants in them. Rather, you should use $_GET, $_POST
>> and $_COOKIE, as appropriate. Additionally, what you actually
>> get depends on the request_order option in the php.ini file, and
>> can change - potentially breaking your code.
>>
>
> Why mention cookie here? He can manipulate everything.
>
> I taught an interface programmer how to test my forms with curl,
> see here http://curl.haxx.se/docs/manpage.html especially the
> --get and --form options.
>
> $_REQUEST is not more dangerous than programming in PHP. q.e.d.
>
> /Str.
Keep thinking that. Those of us concerned about security will keep
using the appropriate values.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176430 is a reply to message #176426] |
Fri, 06 January 2012 18:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 12:05 PM, M. Strobel wrote:
> Am 06.01.2012 11:07, schrieb Erwin Moller:
>> On 1/6/2012 12:28 AM, M. Strobel wrote:
>>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>>
>
> -----------cut on various places
>
>> Hi Strobel,
>>
>> And why do you prefer $_REQUEST over using the exact superglobal?
>> You do know where the information is supposed to come from.
>>
> Yes I know that exactly. But why care? When I expect data I do
>
> function getIntFromForm($key, $def=null) {
> if (isset($_REQUEST[$key])) {
> if ($a = sscanf($_REQUEST[$key], '%d')) { // unsigned
> $def = $a[0];
> } else {
> # keine Zahl im Wert $key / no number
> }
> } else {
> # key nicht gefunden / no key
> }
> return $def;
> }
>
>>
>>>
>>> But then I have to mention my setup with a sort of call
>>> dispatcher: the called function is looked up in a list taking
>>> into account $_SERVER['REQUEST_METHOD'].
>>
>> That explanation makes no sense to me without any more context.
>> Are you saying you are limiting access to certain function by
>> checking the used $_SERVER['REQUEST_METHOD']?
>> If so, that won't help at all, since anybody could still use the
>> "right" REQUEST_METHOD and manipulate the contents of GPC at the
>> same time.
>
> This is correct, it is not a real protection, but part of the
> request processing. And the correct request processing takes care
> to only read in and verify expected data.
>
>>>
>>> All user input must be verified, no matter if it's in $_GET,
>>> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
>>> faked!
>>
>> Of course.
>> But how does that relate to using $_REQUEST over the exact
>> superglobal?
>
> if (is-a-post-operation AND data-expected)
> read post data;
> elseif (is-a-get-operation AND data-expected)
> read get data;
>
> What for? Just do
> if (data-expected) read request data.
>
>
>> If you think I am wrong about that, please tell me why.
>> I had this discussion a few years back too, but the guy turned
>> out to be a troll (and silly me took the bait!), so that turned
>> out to be a dead end.
>
> Always check data on input :-)
>
>>
>> Regards,
>> Erwin Moller
>>
>
> /Str.
You should KNOW whether it is a GET or POST operation, and not allow
hackers to slip things in other ways.
Of course, when you don't care about your sites being hacked, you can do
anything you want.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176431 is a reply to message #176430] |
Fri, 06 January 2012 18:45 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 19:07, schrieb Jerry Stuckle:
> You should KNOW whether it is a GET or POST operation, and not
> allow hackers to slip things in other ways.
>
I never said I do not know if it's a GET or POST operation. On
the contrary.
> Of course, when you don't care about your sites being hacked, you
> can do anything you want.
>
Repetitive.
You did not pick up this:
Why do you need to know exactly if the data is from GET or POST?
Does your program use POST urls with variables in the url?
If yes, did you not take care to have different variable names?
/Str.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176432 is a reply to message #176424] |
Fri, 06 January 2012 19:14 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle schrieb:
> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>> Jerry Stuckle schrieb:
>>
>>> $REQUESTS is quite dangerous. You never know whether it comes from
>>> $_GET, $_POST or $_COOKIE, for instance.
>>
>> True, you don't know. But does it matter?
>
> No, it doesn't matter if you aren't concerned about security.
I was hoping for some objective arguments, but well...
Okay, let me rephrase this. Suppose you have a parameter foo which is
expected to be sent via $_POST only. So if it's being sent via $_GET you
refuse it as invalid. Okay. So all the attacker has to do is send it via
$_POST and you will happily accept it. Now of course you must ensure
that this foo parameter, even if sent via $_POST, can do no evil. You
must properly validate it. But once you're there, you might as well
accept it via $_GET, for what difference does it make now? You validate
it, so it can do no harm.
I repeat: An attacker can send ANYTHING via GET or POST or COOKIE as he
chooses. YOU, therefore, cannot say "this came via POST as intended, so
it's safe". You must not rely on the data source. Therefor, the data
source should be irrelevant to your application and your application
must be designed so that it doesn't matter if the data comes via GET,
POST or COOKIE. In other words: When some evil person knocks on your
door, it really doesn't matter if he came by train or by car to your
doorstep. The same holds for a nice guy visiting you.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176433 is a reply to message #176432] |
Fri, 06 January 2012 19:24 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 20:14, schrieb Thomas Mlynarczyk:
> Jerry Stuckle schrieb:
>> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>>
>>>> $REQUESTS is quite dangerous. You never know whether it comes
>>>> from
>>>> $_GET, $_POST or $_COOKIE, for instance.
>>>
>>> True, you don't know. But does it matter?
>>
>> No, it doesn't matter if you aren't concerned about security.
>
> I was hoping for some objective arguments, but well...
>
> Okay, let me rephrase this. Suppose you have a parameter foo
> which is expected to be sent via $_POST only. So if it's being
> sent via $_GET you refuse it as invalid. Okay. So all the
> attacker has to do is send it via $_POST and you will happily
> accept it. Now of course you must ensure that this foo parameter,
> even if sent via $_POST, can do no evil. You must properly
> validate it. But once you're there, you might as well accept it
> via $_GET, for what difference does it make now? You validate it,
> so it can do no harm.
>
> I repeat: An attacker can send ANYTHING via GET or POST or COOKIE
> as he chooses. YOU, therefore, cannot say "this came via POST as
> intended, so it's safe". You must not rely on the data source.
> Therefor, the data source should be irrelevant to your
> application and your application must be designed so that it
> doesn't matter if the data comes via GET, POST or COOKIE. In
> other words: When some evil person knocks on your door, it really
> doesn't matter if he came by train or by car to your doorstep.
> The same holds for a nice guy visiting you.
>
> Greetings,
> Thomas
>
Quite near to a mathematical proof.
/Str.
To your signature: Dans ce cas ceux qui ont tort ne sont pas
nombreux.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176434 is a reply to message #176432] |
Fri, 06 January 2012 19:34 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>>
>>>> $REQUESTS is quite dangerous. You never know whether it comes from
>>>> $_GET, $_POST or $_COOKIE, for instance.
>>>
>>> True, you don't know. But does it matter?
>>
>> No, it doesn't matter if you aren't concerned about security.
>
> I was hoping for some objective arguments, but well...
>
> Okay, let me rephrase this. Suppose you have a parameter foo which is
> expected to be sent via $_POST only. So if it's being sent via $_GET you
> refuse it as invalid. Okay. So all the attacker has to do is send it via
> $_POST and you will happily accept it. Now of course you must ensure
> that this foo parameter, even if sent via $_POST, can do no evil. You
> must properly validate it. But once you're there, you might as well
> accept it via $_GET, for what difference does it make now? You validate
> it, so it can do no harm.
>
> I repeat: An attacker can send ANYTHING via GET or POST or COOKIE as he
> chooses. YOU, therefore, cannot say "this came via POST as intended, so
> it's safe". You must not rely on the data source. Therefor, the data
> source should be irrelevant to your application and your application
> must be designed so that it doesn't matter if the data comes via GET,
> POST or COOKIE. In other words: When some evil person knocks on your
> door, it really doesn't matter if he came by train or by car to your
> doorstep. The same holds for a nice guy visiting you.
>
> Greetings,
> Thomas
>
well its a shade easier for a script kiddie to set a get variable than a
post and a bit harder to set a cookie...
But the whole thing is all about the context in which you are running a
website.
(Or Jerry's ego, whatever)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176435 is a reply to message #176434] |
Fri, 06 January 2012 20:11 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 06.01.2012 20:34, schrieb The Natural Philosopher:
> well its a shade easier for a script kiddie to set a get variable
> than a post and a bit harder to set a cookie...
One might think. But isn't a script kiddie someone who starts a
crack program and and klicks on some checkboxes without knowing
what happens? These programs can do quite complex attacks.
And then look at http://curl.haxx.se/docs/manual.html the section
about cookies.
/Str.
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176436 is a reply to message #176431] |
Fri, 06 January 2012 23:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 1:45 PM, M. Strobel wrote:
> Am 06.01.2012 19:07, schrieb Jerry Stuckle:
>> You should KNOW whether it is a GET or POST operation, and not
>> allow hackers to slip things in other ways.
>>
>
> I never said I do not know if it's a GET or POST operation. On
> the contrary.
>
>> Of course, when you don't care about your sites being hacked, you
>> can do anything you want.
>>
> Repetitive.
>
> You did not pick up this:
>
> Why do you need to know exactly if the data is from GET or POST?
> Does your program use POST urls with variables in the url?
>
> If yes, did you not take care to have different variable names?
>
> /Str.
Because I only allow POST operations on specific pages and GET
operations on others. And I do not allow values from one type operation
to be mixed with values of the other, or with cookies.
But then I care about security.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176437 is a reply to message #176432] |
Fri, 06 January 2012 23:12 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/6/2012 2:14 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>> On 1/6/2012 6:05 AM, Thomas Mlynarczyk wrote:
>>> Jerry Stuckle schrieb:
>>>
>>>> $REQUESTS is quite dangerous. You never know whether it comes from
>>>> $_GET, $_POST or $_COOKIE, for instance.
>>>
>>> True, you don't know. But does it matter?
>>
>> No, it doesn't matter if you aren't concerned about security.
>
> I was hoping for some objective arguments, but well...
>
> Okay, let me rephrase this. Suppose you have a parameter foo which is
> expected to be sent via $_POST only. So if it's being sent via $_GET you
> refuse it as invalid. Okay. So all the attacker has to do is send it via
> $_POST and you will happily accept it. Now of course you must ensure
> that this foo parameter, even if sent via $_POST, can do no evil. You
> must properly validate it. But once you're there, you might as well
> accept it via $_GET, for what difference does it make now? You validate
> it, so it can do no harm.
>
> I repeat: An attacker can send ANYTHING via GET or POST or COOKIE as he
> chooses. YOU, therefore, cannot say "this came via POST as intended, so
> it's safe". You must not rely on the data source. Therefor, the data
> source should be irrelevant to your application and your application
> must be designed so that it doesn't matter if the data comes via GET,
> POST or COOKIE. In other words: When some evil person knocks on your
> door, it really doesn't matter if he came by train or by car to your
> doorstep. The same holds for a nice guy visiting you.
>
> Greetings,
> Thomas
>
I didn't say you didn't need to validate the parameter. But limiting
values to the proper operation makes it harder for hackers to break in.
It DOES matter where it came from - and data coming in from the wrong
variable can get their IP blocked from the site. There is no use making
it easy for them.
I have people trying to break into the sites I designed almost daily
(multiple times daily if you also include SMTP and SSH attacks). None
have succeeded.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]