Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4177 > unrolled thread

Magic quotes? Should I still be cautious?

Back to article view | Back to comp.lang.php

Contents

  Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-29 15:55 -0500
    Re: Magic quotes? Should I still be cautious? Michael Fesser <netizen@gmx.de> - 2011-12-29 22:04 +0100
      Re: Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-29 16:53 -0500
        Re: Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-29 17:08 -0500
      Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2011-12-29 23:22 +0100
    Re: Magic quotes? Should I still be cautious? "Peter H. Coffin" <hellsop@ninehells.com> - 2011-12-29 17:53 -0600
      Re: Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-29 23:32 -0500
        Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-12-30 12:38 +0100
          Re: Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-30 09:52 -0500
            Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-02 15:02 +0100
        Re: Magic quotes? Should I still be cautious? Michael Fesser <netizen@gmx.de> - 2011-12-30 13:18 +0100
    Re: Magic quotes? Should I still be cautious? "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-12-30 10:26 +0100
    Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-12-30 14:42 +0100
      Re: Magic quotes? Should I still be cautious? Michael Joel <no@please.com> - 2011-12-30 09:52 -0500
    Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-04 15:55 +0100
      Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-05 14:08 +0100
        Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-05 14:22 +0100
          Re: Magic quotes? Should I still be cautious? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-05 13:36 +0000
            Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-05 15:20 +0100
              Re: Magic quotes? Should I still be cautious? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-05 15:49 +0000
          Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-05 14:39 +0100
        Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 00:28 +0100
          Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-05 19:36 -0500
            Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-06 11:16 +0100
            Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-06 12:05 +0100
              Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 08:32 -0500
                Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 18:18 +0100
                  Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 13:04 -0500
                  Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-08 20:48 +0100
                Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-06 20:14 +0100
                  Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 20:24 +0100
                  Re: Magic quotes? Should I still be cautious? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-06 19:34 +0000
                    Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 21:11 +0100
                  Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 18:12 -0500
                    Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-07 17:59 +0100
                      Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-07 15:54 -0500
                        Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-08 02:13 +0100
                          Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-07 20:33 -0500
                            Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-09 00:21 +0100
                              Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 19:05 -0500
                    Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-08 20:52 +0100
                      Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-08 15:59 -0500
                        Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-11 11:00 +0100
                          Re: Magic quotes? Should I still be cautious? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-11 11:53 +0000
                            Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-11 08:45 -0500
                            Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-11 15:43 +0100
                          Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-11 08:44 -0500
                            Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-11 15:47 +0100
                              Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-11 09:51 -0500
                                Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-11 18:09 +0100
                                  Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-11 14:01 -0500
                                    Re: Magic quotes? Should I still be cautious? Arno Welzel <usenet@arnowelzel.de> - 2012-01-12 08:58 +0100
            Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 17:41 +0100
              Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 13:05 -0500
          Re: Magic quotes? Should I still be cautious? Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2012-01-06 11:07 +0100
            Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 18:05 +0100
              Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 13:07 -0500
                Re: Magic quotes? Should I still be cautious? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-06 19:45 +0100
                  Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-06 18:09 -0500
                    Re: Magic quotes? Should I still be cautious? Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-01-07 18:08 +0100
                      Re: Magic quotes? Should I still be cautious? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-07 15:59 -0500

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#4223

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

[toc] | [prev] | [next] | [standalone]

#4226

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.

[toc] | [prev] | [next] | [standalone]

#4227

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4229

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

[toc] | [prev] | [next] | [standalone]

#4230

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)

[toc] | [prev] | [next] | [standalone]

#4231

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4234

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

[toc] | [prev] | [next] | [standalone]

#4235

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4315

M. Strobel, 2012-01-06 18:18:

> 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

[toc] | [prev] | [next] | [standalone]

#4239

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)

[toc] | [prev] | [next] | [standalone]

#4240

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.

[toc] | [prev] | [next] | [standalone]

#4241

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)

[toc] | [prev] | [next] | [standalone]

#4242

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.

[toc] | [prev] | [next] | [standalone]

#4244

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4260

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?

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)

[toc] | [prev] | [next] | [standalone]

#4269

On 1/7/2012 11:59 AM, Thomas Mlynarczyk wrote:
> 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
==================

[toc] | [prev] | [next] | [standalone]

#4276

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.

> 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)

[toc] | [prev] | [next] | [standalone]

#4277

On 1/7/2012 8:13 PM, Thomas Mlynarczyk wrote:
> 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
==================

[toc] | [prev] | [next] | [standalone]

#4327

Jerry Stuckle schrieb:

> 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)

[toc] | [prev] | [next] | [standalone]

#4331

On 1/8/2012 6:21 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> 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.
>

If they are supposed to be sent by POST and are instead sent by GET, 
then by definition they are NOT "good guys".  Detecting things sent via 
the "wrong" method is one way to detect attacks.

> 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.
>

Just because a user is logged in doesn't make any difference.  Hackers 
will commonly use throw-away email addresses and sign up for sites.

Unless you are going to limit access to those you personally know, and 
authorize each one.

> 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
>

I didn't say you can't prevent an attack without checking which way the 
variable came from.  I said that is one way to detect attacks.

The sooner you can detect an attack, the sooner (and easier) you can 
prevent it.  A basic tenet of security.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web