FUDforum - خوراک RDF
http://fudforum.org/forum/index.php
Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176378&th=122470#msg_176378
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]]>Michael Joel2011-12-29T20:55:10-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176379&th=122470#msg_176379
> 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
-- http://mfesser.de/blickwinkel]]>Michael Fesser2011-12-29T21:04:13-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176380&th=122470#msg_176380
netizen@gmx.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]]>Michael Joel2011-12-29T21:53:17-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176381&th=122470#msg_176381
no@please.com>
wrote:
> On Thu, 29 Dec 2011 22:04:13 +0100, Michael Fesser <netizen@gmx.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]]>Michael Joel2011-12-29T22:08:36-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176382&th=122470#msg_176382
> 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)]]>Thomas Mlynarczyk2011-12-29T22:22:00-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176386&th=122470#msg_176386
> 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]]>Peter H. Coffin2011-12-29T23:53:09-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176388&th=122470#msg_176388
<hellsop@ninehells.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]]>Michael Joel2011-12-30T04:32:17-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176390&th=122470#msg_176390
> 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
--]]>alvaro.NOSPAMTHANX2011-12-30T09:26:48-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176393&th=122470#msg_176393
> On Thu, 29 Dec 2011 17:53:09 -0600, "Peter H. Coffin"
> <hellsop@ninehells.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]]>Erwin Moller2011-12-30T11:38:01-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176394&th=122470#msg_176394
> 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]]>Michael Fesser2011-12-30T12:18:20-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176395&th=122470#msg_176395
> 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]]>Erwin Moller2011-12-30T13:42:43-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176396&th=122470#msg_176396
<Since_humans_read_this_I_am_spammed_too_much@spamyourself.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@ninehells.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]]>Michael Joel2011-12-30T14:52:04-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176397&th=122470#msg_176397
<Since_humans_read_this_I_am_spammed_too_much@spamyourself.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]]>Michael Joel2011-12-30T14:52:56-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176405&th=122470#msg_176405
> On Fri, 30 Dec 2011 12:38:01 +0100, Erwin Moller
> <Since_humans_read_this_I_am_spammed_too_much@spamyourself.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@ninehells.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]]>Erwin Moller2012-01-02T14:02:55-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176412&th=122470#msg_176412
> 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:
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de]]>Arno Welzel2012-01-04T14:55:51-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176413&th=122470#msg_176413
> 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.
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);
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens]]>Erwin Moller2012-01-05T13:08:13-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176414&th=122470#msg_176414
> 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]]>Arno Welzel2012-01-05T13:22:25-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176415&th=122470#msg_176415
> 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.]]>The Natural Philosoph2012-01-05T13:36:56-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176416&th=122470#msg_176416
> 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"];
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]]>Erwin Moller2012-01-05T13:39:52-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176417&th=122470#msg_176417
> 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]]>Erwin Moller2012-01-05T14:20:44-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176418&th=122470#msg_176418
> 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..]]>The Natural Philosoph2012-01-05T15:49:11-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176419&th=122470#msg_176419
>
> 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.]]>M. Strobel2012-01-05T23:28:09-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176420&th=122470#msg_176420
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T00:36:59-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176421&th=122470#msg_176421
> 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:
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]]>Erwin Moller2012-01-06T10:07:48-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176422&th=122470#msg_176422
> 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]]>Erwin Moller2012-01-06T10:16:38-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176423&th=122470#msg_176423
> $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)]]>Thomas Mlynarczyk2012-01-06T11:05:10-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176424&th=122470#msg_176424
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T13:32:25-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176425&th=122470#msg_176425
> 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.]]>M. Strobel2012-01-06T16:41:13-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176426&th=122470#msg_176426
> 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.]]>M. Strobel2012-01-06T17:05:17-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176427&th=122470#msg_176427
> 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]]>M. Strobel2012-01-06T17:18:35-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176428&th=122470#msg_176428
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T18:04:41-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176429&th=122470#msg_176429
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T18:05:36-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176430&th=122470#msg_176430
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T18:07:07-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176431&th=122470#msg_176431
> 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.]]>M. Strobel2012-01-06T18:45:57-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176432&th=122470#msg_176432
> 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)]]>Thomas Mlynarczyk2012-01-06T19:14:17-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176433&th=122470#msg_176433
> 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.]]>M. Strobel2012-01-06T19:24:36-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176434&th=122470#msg_176434
> 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)]]>The Natural Philosoph2012-01-06T19:34:49-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176435&th=122470#msg_176435
> 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.
/Str.]]>M. Strobel2012-01-06T20:11:45-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176436&th=122470#msg_176436
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T23:09:08-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176437&th=122470#msg_176437
> 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@attglobal.net
==================]]>Jerry Stuckle2012-01-06T23:12:13-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176453&th=122470#msg_176453
> 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.
Harder? Well, by a microscopically tiny amount, yes. The Web Developer's
Toolbar on Firefox has a menu allowing me to change POSTs to GETs and
vice versa. And I'm sure with Google you can find in 5 minutes a tool
that lets you choose between GET, POST and COOKIE and has many other
"hacking features". So, for all practical purposes, I do not consider
this to make it any harder for hackers.
> 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.
Yes, but I still feel that this "where-did-it-come-from" check in
addition to the proper validation you have to do anyway is like putting
a banana peel on the floor so in case the enemy manages to force the
iron gate guarded by a three-headed dragon they will slip on it and
break their neck.
Let's consider an example: A site is available in several languages and
the user can choose a language by clicking on a link (which sends a GET
variable like "lang=de"). The selected language will be stored in a
cookie ("lang=de"), so next time the user visits the site their
preferred language will already be selected. Now on every request the
site checks if there is a "lang" variable (coming from any source) and
sets the proper language accordingly and if the language differs from
the previous one, the lang cookie will be set. A forced distinction
between GET and COOKIE doesn't seem very intelligent to me here. And
even if lang came via POST -- what would it matter?
But lets say we have something more serious, like "delete=all", supposed
to come via POST. Sure, if this came via COOKIE it would certainly be
wrong. If it came via GET, well, there might be a legitimate reason --
or not. But even if it comes via POST, I would not accept it unless I
have a valid session with a valid user logged in who has the privilege
to delete "all". A script kiddie might try to send "delete=all" via GET,
but my three-headed dragon at the iron gate should politely refuse that
request. And if the script kiddie is smart enough to hijack the session
of a sufficiently privileged user, they will surely not be stupid enough
to slip on the GET/POST banana peel.
> 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.
Would they have succeeded had you allowed any of the three input
sources? Yes? Then your site is not safe, but it's certainly not due to
that. No? Well, see, I was right ;-)
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)]]>Thomas Mlynarczyk2012-01-07T16:59:36-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176455&th=122470#msg_176455
> Because I only allow POST operations on specific pages and GET
> operations on others.
You set those permissions "by page" rather than "by action"?
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)]]>Thomas Mlynarczyk2012-01-07T17:08:00-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176462&th=122470#msg_176462
> Jerry Stuckle schrieb:
>
>> 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.
>
> Harder? Well, by a microscopically tiny amount, yes. The Web Developer's
> Toolbar on Firefox has a menu allowing me to change POSTs to GETs and
> vice versa. And I'm sure with Google you can find in 5 minutes a tool
> that lets you choose between GET, POST and COOKIE and has many other
> "hacking features". So, for all practical purposes, I do not consider
> this to make it any harder for hackers.
>
>> 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.
>
> Yes, but I still feel that this "where-did-it-come-from" check in
> addition to the proper validation you have to do anyway is like putting
> a banana peel on the floor so in case the enemy manages to force the
> iron gate guarded by a three-headed dragon they will slip on it and
> break their neck.
>
> Let's consider an example: A site is available in several languages and
> the user can choose a language by clicking on a link (which sends a GET
> variable like "lang=de"). The selected language will be stored in a
> cookie ("lang=de"), so next time the user visits the site their
> preferred language will already be selected. Now on every request the
> site checks if there is a "lang" variable (coming from any source) and
> sets the proper language accordingly and if the language differs from
> the previous one, the lang cookie will be set. A forced distinction
> between GET and COOKIE doesn't seem very intelligent to me here. And
> even if lang came via POST -- what would it matter?
>
Which would be incorrect. Because if it comes from a cookie, there is
no need to display the language selection page or options (unless the
user requests a different language). There is also no need to set the
cookie.
However, if there is no language cookie set (or the user says he wants a
different language), then the language selection page must be displayed
and the correct response coming from the $_GET or $_POST variable, as
appropriate.
There is another problem with your way, also. If the server
configuration is set such that cookies take precedence over GET or POST
values, then the user would never be able to change the language by
using $_REQUEST. And since this is server-configuration sensitive,
changes to the server configuration or moving to a different server can
break otherwise working code.
> But lets say we have something more serious, like "delete=all", supposed
> to come via POST. Sure, if this came via COOKIE it would certainly be
> wrong. If it came via GET, well, there might be a legitimate reason --
> or not. But even if it comes via POST, I would not accept it unless I
> have a valid session with a valid user logged in who has the privilege
> to delete "all". A script kiddie might try to send "delete=all" via GET,
> but my three-headed dragon at the iron gate should politely refuse that
> request. And if the script kiddie is smart enough to hijack the session
> of a sufficiently privileged user, they will surely not be stupid enough
> to slip on the GET/POST banana peel.
>
There would not be a legitimate reason if the only way to set the value
would be from a page via method=POST.
>> 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.
>
> Would they have succeeded had you allowed any of the three input
> sources? Yes? Then your site is not safe, but it's certainly not due to
> that. No? Well, see, I was right ;-)
>
> Greetings,
> Thomas
>
It's much less likely when you validate the values via the appropriate
method. And if someone does try to send "delete=all" via $_GET, that ip
can quickly be barred from any access to the site, stopping the hacker
before they can try other methods.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-01-07T20:54:28-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176464&th=122470#msg_176464
> Jerry Stuckle schrieb:
>
>> Because I only allow POST operations on specific pages and GET
>> operations on others.
>
> You set those permissions "by page" rather than "by action"?
>
> Greetings,
> Thomas
>
I know what page(s) can legitimately access the page in question.
Operations which change the database can only be accessed via POST
operations, for instance. Accessing them via GET will not do anything.
But then my pages process the data entered, also. For instance, if
someone wants to log in, they can access the page via GET, in which case
the page will only be displayed. When they enter their userid and
password, the form's action directs to the same page as a POST. When the
POST operation comes in (and only then), the userid and password are
validated, and if correct, redirect to the next page via a header() call.
And no, I do NOT want these values to come in via a cookie or a GET request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-01-07T20:59:18-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176469&th=122470#msg_176469
>> Let's consider an example: A site is available in several languages and
>> the user can choose a language by clicking on a link (which sends a GET
>> variable like "lang=de"). The selected language will be stored in a
>> cookie ("lang=de"), so next time the user visits the site their
>> preferred language will already be selected. Now on every request the
>> site checks if there is a "lang" variable (coming from any source) and
>> sets the proper language accordingly and if the language differs from
>> the previous one, the lang cookie will be set. A forced distinction
>> between GET and COOKIE doesn't seem very intelligent to me here. And
>> even if lang came via POST -- what would it matter?
>
> Which would be incorrect. Because if it comes from a cookie, there is
> no need to display the language selection page or options (unless the
> user requests a different language). There is also no need to set the
> cookie.
The language selection/options are always displayed, the current
language being "highlighted" or otherwise emphasized. And the cookie is
set only if the choosen new language differs from the current language.
Yes, that means when a new session is started and the cookie with the
previous selection is sent, there will be one unnecessary setcookie()
call, which, however, will do no harm. Alternatively, the user might
have bookmarked a link containing the lang GET parameter... it's really
simpler and more convenient to ignore the source of the lang parameter
here and I definitely do not see any security issue here.
> There is another problem with your way, also. If the server
> configuration is set such that cookies take precedence over GET or POST
> values, then the user would never be able to change the language by
> using $_REQUEST. And since this is server-configuration sensitive,
> changes to the server configuration or moving to a different server can
> break otherwise working code.
This is absolutely true and I had mentioned it some postings ago. And
actually I would not use $_REQUEST, but rather write a utility input
function that will look for the desired parameter in GET, POST, COOKIE
(in precisely that order), but using the filter_input() function instead
of the superglobals (to avoid the magic quotes issue). This way I'm not
dependent on the server configuration.
>> But lets say we have something more serious, like "delete=all", supposed
>> to come via POST. Sure, if this came via COOKIE it would certainly be
>> wrong. If it came via GET, well, there might be a legitimate reason --
> There would not be a legitimate reason if the only way to set the value
> would be from a page via method=POST.
I may want or need a link to "delete=all" in addition to the form on
some other page. My business logic should not be concerned with
presentation issues (such as on which page the delete command appears).
After all, whether it's a link (GET) or a form (POST) is just a matter
of presentation. In both cases I must verify that there is a valid
session, a valid user etc. I know it is semantically wrong to use GET
for something like "delete", but then this is just an example.
My point is that the concept of GET, POST and COOKIE is a thing with the
HTTP protocol. My web application is one level above that and should
thus not be concerned with the low-level details. And I repeat: an evil
guy can send an evil command by any of the three ways and thus I
consider it pointless, if not risky, to put any relevance on this. My
main focus is not to detect an attack, but to prevent it. Checking
whence the variable came might help detecting some attacks, but proper
input validation will prevent it and with the latter in place just let
the attacker come by GET, POST, COOKIE or whatever, it won't make a
difference.
> It's much less likely when you validate the values via the appropriate
> method. And if someone does try to send "delete=all" via $_GET, that ip
> can quickly be barred from any access to the site, stopping the hacker
> before they can try other methods.
Hm. You seem to be focussed on detecting an attack, rather than on
preventing it (I'm not saying you are neglecting the latter). An analogy
just came to my mind: in JavaScript you could check the user agent to
find out if a special feature is supported or you could test for that
feature directly. Of course it is simpler and more effective to do the
latter than the former. The checking where the variable came from is a
bit like browser sniffing.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)]]>Thomas Mlynarczyk2012-01-08T01:13:19-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176470&th=122470#msg_176470
> Jerry Stuckle schrieb:
>>> Let's consider an example: A site is available in several languages and
>>> the user can choose a language by clicking on a link (which sends a GET
>>> variable like "lang=de"). The selected language will be stored in a
>>> cookie ("lang=de"), so next time the user visits the site their
>>> preferred language will already be selected. Now on every request the
>>> site checks if there is a "lang" variable (coming from any source) and
>>> sets the proper language accordingly and if the language differs from
>>> the previous one, the lang cookie will be set. A forced distinction
>>> between GET and COOKIE doesn't seem very intelligent to me here. And
>>> even if lang came via POST -- what would it matter?
>>
>> Which would be incorrect. Because if it comes from a cookie, there is
>> no need to display the language selection page or options (unless the
>> user requests a different language). There is also no need to set the
>> cookie.
>
> The language selection/options are always displayed, the current
> language being "highlighted" or otherwise emphasized. And the cookie is
> set only if the choosen new language differs from the current language.
> Yes, that means when a new session is started and the cookie with the
> previous selection is sent, there will be one unnecessary setcookie()
> call, which, however, will do no harm. Alternatively, the user might
> have bookmarked a link containing the lang GET parameter... it's really
> simpler and more convenient to ignore the source of the lang parameter
> here and I definitely do not see any security issue here.
>
That's your first mistake. Cookies are completely unrelated to sessions
- except for the session id in PHP. So there is no need for an extra
setcookie() call - except when you have screwed up logic.
>> There is another problem with your way, also. If the server
>> configuration is set such that cookies take precedence over GET or
>> POST values, then the user would never be able to change the language
>> by using $_REQUEST. And since this is server-configuration sensitive,
>> changes to the server configuration or moving to a different server
>> can break otherwise working code.
>
> This is absolutely true and I had mentioned it some postings ago. And
> actually I would not use $_REQUEST, but rather write a utility input
> function that will look for the desired parameter in GET, POST, COOKIE
> (in precisely that order), but using the filter_input() function instead
> of the superglobals (to avoid the magic quotes issue). This way I'm not
> dependent on the server configuration.
>
Or, rather, look for it where you EXPECT it to occur, and nowhere else.
>>> But lets say we have something more serious, like "delete=all", supposed
>>> to come via POST. Sure, if this came via COOKIE it would certainly be
>>> wrong. If it came via GET, well, there might be a legitimate reason --
>
>> There would not be a legitimate reason if the only way to set the
>> value would be from a page via method=POST.
>
There is no way to ensure the value isn't set via a cookie or GET
request. A hacker can easily send it any way he wants. This is a very
basic security concept.
> I may want or need a link to "delete=all" in addition to the form on
> some other page. My business logic should not be concerned with
> presentation issues (such as on which page the delete command appears).
> After all, whether it's a link (GET) or a form (POST) is just a matter
> of presentation. In both cases I must verify that there is a valid
> session, a valid user etc. I know it is semantically wrong to use GET
> for something like "delete", but then this is just an example.
>
Yes and no. Business logic should not be concerned with presentation
issues - but the interface logic MUST be concerned with it for good
security.
> My point is that the concept of GET, POST and COOKIE is a thing with the
> HTTP protocol. My web application is one level above that and should
> thus not be concerned with the low-level details. And I repeat: an evil
> guy can send an evil command by any of the three ways and thus I
> consider it pointless, if not risky, to put any relevance on this. My
> main focus is not to detect an attack, but to prevent it. Checking
> whence the variable came might help detecting some attacks, but proper
> input validation will prevent it and with the latter in place just let
> the attacker come by GET, POST, COOKIE or whatever, it won't make a
> difference.
>
Your web application may be one level above that. But you obviously
don't understand how to properly interface your business logic to the
display logic.
>> It's much less likely when you validate the values via the appropriate
>> method. And if someone does try to send "delete=all" via $_GET, that
>> ip can quickly be barred from any access to the site, stopping the
>> hacker before they can try other methods.
>
> Hm. You seem to be focussed on detecting an attack, rather than on
> preventing it (I'm not saying you are neglecting the latter). An analogy
> just came to my mind: in JavaScript you could check the user agent to
> find out if a special feature is supported or you could test for that
> feature directly. Of course it is simpler and more effective to do the
> latter than the former. The checking where the variable came from is a
> bit like browser sniffing.
>
> Greetings,
> Thomas
>
That is correct. Detection is always the first step in prevention, as
anyone familiar with security understands. You cannot prevent something
you cannot detect.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-01-08T01:33:15-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176508&th=122470#msg_176508
> 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.
In fact, PHP has a lot of "historical" security flaws and i agree it is
not a good idea to use $_REQUEST instead of $_POST or $_GET.
My "hack" to avoid Magic Quotes without changing existing code uses
$_REQUEST only, because existing code - which may not be my own code -
may rely on it.
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de]]>Arno Welzel2012-01-08T19:48:22-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176509&th=122470#msg_176509
[...]
> 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.
So you also check, if a parameter is *not* passed as GET if you expect
it as POST? Because otherwise this "security check" would not make any
sense.
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de]]>Arno Welzel2012-01-08T19:52:18-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176512&th=122470#msg_176512
> Jerry Stuckle, 2012-01-07 00:12:
>
> [...]
>> 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.
>
> So you also check, if a parameter is *not* passed as GET if you expect
> it as POST? Because otherwise this "security check" would not make any
> sense.
>
>
>
Where security is important, yes. And if I see suspicious activity I
block the IP. But more often than not, they try to pass POST data in a
GET request (because it's so easy). It's quite easy to ensure that data
which should only be passed in a POST request isn't coming in the GET
request.
But even more importantly, I ensure that data coming from a POST request
is ONLY coming via $_POST - and not a mixture of $_GET and $_POST. It's
another trick hackers will do.
I do other things also, but don't want to get into too much detail in a
public forum.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-01-08T20:59:58-00:00Re: Magic quotes? Should I still be cautious?
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=176520&th=122470#msg_176520
> That's your first mistake. Cookies are completely unrelated to sessions
> - except for the session id in PHP. So there is no need for an extra
> setcookie() call - except when you have screwed up logic.
Maybe there is some misunderstanding here.
> There is no way to ensure the value isn't set via a cookie or GET
> request. A hacker can easily send it any way he wants. This is a very
> basic security concept.
Yes, that's what I'm saying: A hacker can send it any way he wants.
> Detection is always the first step in prevention, as
> anyone familiar with security understands. You cannot prevent something
> you cannot detect.
Assume a variable is supposed to be sent via POST. Now there are the
good guys and the bad guys. The good guys will, by definition, always
send that variable via POST as intended. For /them/, we don't need any
checks and we might even allow them to send it via GET, because we know
they're the good guys. The bad guys /can/ send it via POST as well.
Thus, your website must be able to withstand an attack coming via the
"right" method. But if your website can withstand such an attack, it can
automatically also withstand an attack via the "wrong" method. So you're
safe, without needing to check for the method.
To accept a "delete=all", there must be a session, a properly logged-in
user etc. and that command must be accompanied by a one-time token your
website generates whenever the delete form is displayed. If there is no
security flaw in this, then it is either impossible for the command to
come via GET instead of POST without failing at least one of the other
conditions or it *is* valid (I can tell my Firefox to change POSTs to
GETs and vice versa). And if there /is/ a security flaw in this, then it
is certainly something which is not related to the input method, but
must be some "deeper" problem.
In other words: If I cannot prevent an attack *without* checking which
way the variable came, then my security is no good. But if I can prevent
an attack without checking this, then why should I bother checking?
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)]]>Thomas Mlynarczyk2012-01-08T23:21:20-00:00