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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#4316

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.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4319

On 1/8/2012 2:52 PM, Arno Welzel wrote:
> 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
==================

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

#4413

Jerry Stuckle, 2012-01-08 21:59:

[...]
> I do other things also, but don't want to get into too much detail in a 
> public forum.

"Security by obscurity" does not work. If your security only relies on
the fact, that you try to keep the procedures or code a secret, it is
flawed.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4415

Arno Welzel wrote:
> Jerry Stuckle, 2012-01-08 21:59:
> 
> [...]
>> I do other things also, but don't want to get into too much detail in a 
>> public forum.
> 
> "Security by obscurity" does not work.

actually it does. It is the basis for all passwords for example.


  If your security only relies on
> the fact, that you try to keep the procedures or code a secret, it is
> flawed.
> 
> 
> 

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

#4419

On 1/11/2012 6:53 AM, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Jerry Stuckle, 2012-01-08 21:59:
>>
>> [...]
>>> I do other things also, but don't want to get into too much detail in
>>> a public forum.
>>
>> "Security by obscurity" does not work.
>
> actually it does. It is the basis for all passwords for example.
>
>

Another proof that TNP has no idea what he's doing.


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

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

#4421

The Natural Philosopher, 2012-01-11 12:53:

> Arno Welzel wrote:
>> Jerry Stuckle, 2012-01-08 21:59:
>>
>> [...]
>>> I do other things also, but don't want to get into too much detail in a 
>>> public forum.
>>
>> "Security by obscurity" does not work.
> 
> actually it does. It is the basis for all passwords for example.

I did'nt talk about passwords m( but *procedures*. And a secret password
is not "security by obscurity".

In cryptography this is the most important principle: Keep the password
or private key as a secret but not the procedure - and cryptographic
procedures which are not documented have to be considered insecure.

If you say "i do something in my application to keep it secure, but i
won't tell anybody what this is - because if i would, a hacker could use
this information to attack my application" - then your procedure is
flawed, since you risk that the whole thing may fail as soon as someone
find's out, how it works.

I procedure has to be secure *even* when everybody knows how it works.

For example: A packet filter in Linux is also not secure because nobody
knows how it works.

Or another example: A user database must never store plain text
passwords but only in an encrypted form - but the procedure of the
encryption must be documented. Otherwise you never will know, if there
are flaws in the procedure which are already used by attackers. And if
you are not an expert in cryptography don't even think about creating
your own "secure" encryption - and the same often also applies to code
which is considered to be "secure" against attacks.

>   If your security only relies on
>> the fact, that you try to keep the procedures or code a secret, it is
>> flawed.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4418

On 1/11/2012 5:00 AM, Arno Welzel wrote:
> Jerry Stuckle, 2012-01-08 21:59:
>
> [...]
>> I do other things also, but don't want to get into too much detail in a
>> public forum.
>
> "Security by obscurity" does not work. If your security only relies on
> the fact, that you try to keep the procedures or code a secret, it is
> flawed.
>
>
>

No, security by obscurity does not work.  But that does not mean one 
should broadcast to the world everything he does.

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

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

#4422

Jerry Stuckle, 2012-01-11 14:44:

> On 1/11/2012 5:00 AM, Arno Welzel wrote:
>> Jerry Stuckle, 2012-01-08 21:59:
>>
>> [...]
>>> I do other things also, but don't want to get into too much detail in a
>>> public forum.
>>
>> "Security by obscurity" does not work. If your security only relies on
>> the fact, that you try to keep the procedures or code a secret, it is
>> flawed.
> 
> No, security by obscurity does not work.  But that does not mean one 
> should broadcast to the world everything he does.

Of course it is not neccessary to publish every detail about the
procedures to avoid spam, attacks etc. - but some basic procedures
should be discussed in public, since you might often think you are
"secure" but you just didn't see the flaws in your procedures yet.

For example: I use SpamAssassin and do greylisting on my server. If i
would get less spam just because i keep this information a secret then
SpamAssassin itself and greylistign should be considered useless.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4423

On 1/11/2012 9:47 AM, Arno Welzel wrote:
> Jerry Stuckle, 2012-01-11 14:44:
>
>> On 1/11/2012 5:00 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 2012-01-08 21:59:
>>>
>>> [...]
>>>> I do other things also, but don't want to get into too much detail in a
>>>> public forum.
>>>
>>> "Security by obscurity" does not work. If your security only relies on
>>> the fact, that you try to keep the procedures or code a secret, it is
>>> flawed.
>>
>> No, security by obscurity does not work.  But that does not mean one
>> should broadcast to the world everything he does.
>
> Of course it is not neccessary to publish every detail about the
> procedures to avoid spam, attacks etc. - but some basic procedures
> should be discussed in public, since you might often think you are
> "secure" but you just didn't see the flaws in your procedures yet.
>
> For example: I use SpamAssassin and do greylisting on my server. If i
> would get less spam just because i keep this information a secret then
> SpamAssassin itself and greylistign should be considered useless.
>
>

In your opinion, anyway.  Security experts (which I don't claim to be - 
but know several) disagree.  There is no reason to draw a map to your 
house even if the door is locked.

Additionally, it is off topic in this newsgroup.

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

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

#4425

Jerry Stuckle, 2012-01-11 15:51:

> On 1/11/2012 9:47 AM, Arno Welzel wrote:
>> Jerry Stuckle, 2012-01-11 14:44:
>>
>>> On 1/11/2012 5:00 AM, Arno Welzel wrote:
>>>> Jerry Stuckle, 2012-01-08 21:59:
>>>>
>>>> [...]
>>>>> I do other things also, but don't want to get into too much detail in a
>>>>> public forum.
>>>>
>>>> "Security by obscurity" does not work. If your security only relies on
>>>> the fact, that you try to keep the procedures or code a secret, it is
>>>> flawed.
>>>
>>> No, security by obscurity does not work.  But that does not mean one
>>> should broadcast to the world everything he does.
>>
>> Of course it is not neccessary to publish every detail about the
>> procedures to avoid spam, attacks etc. - but some basic procedures
>> should be discussed in public, since you might often think you are
>> "secure" but you just didn't see the flaws in your procedures yet.
>>
>> For example: I use SpamAssassin and do greylisting on my server. If i
>> would get less spam just because i keep this information a secret then
>> SpamAssassin itself and greylistign should be considered useless.
>>
>>
> 
> In your opinion, anyway.  Security experts (which I don't claim to be - 
> but know several) disagree.  There is no reason to draw a map to your 
> house even if the door is locked.

Well - usually you don't need to draw a map to a house, since maps of
most areas in the world already exist. Did you mean "no reason to
publish the address of a house..."? But where does this end... "no
reason to do let anyone even know you exist at all?" *scnr*

Concerning PHP: Code is not more secure, just because it is closed
source. I don't think, that any security expert will tell the opposite.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4427

On 1/11/2012 12:09 PM, Arno Welzel wrote:
> Jerry Stuckle, 2012-01-11 15:51:
>
>> On 1/11/2012 9:47 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 2012-01-11 14:44:
>>>
>>>> On 1/11/2012 5:00 AM, Arno Welzel wrote:
>>>>> Jerry Stuckle, 2012-01-08 21:59:
>>>>>
>>>>> [...]
>>>>>> I do other things also, but don't want to get into too much detail in a
>>>>>> public forum.
>>>>>
>>>>> "Security by obscurity" does not work. If your security only relies on
>>>>> the fact, that you try to keep the procedures or code a secret, it is
>>>>> flawed.
>>>>
>>>> No, security by obscurity does not work.  But that does not mean one
>>>> should broadcast to the world everything he does.
>>>
>>> Of course it is not neccessary to publish every detail about the
>>> procedures to avoid spam, attacks etc. - but some basic procedures
>>> should be discussed in public, since you might often think you are
>>> "secure" but you just didn't see the flaws in your procedures yet.
>>>
>>> For example: I use SpamAssassin and do greylisting on my server. If i
>>> would get less spam just because i keep this information a secret then
>>> SpamAssassin itself and greylistign should be considered useless.
>>>
>>>
>>
>> In your opinion, anyway.  Security experts (which I don't claim to be -
>> but know several) disagree.  There is no reason to draw a map to your
>> house even if the door is locked.
>
> Well - usually you don't need to draw a map to a house, since maps of
> most areas in the world already exist. Did you mean "no reason to
> publish the address of a house..."? But where does this end... "no
> reason to do let anyone even know you exist at all?" *scnr*
>
> Concerning PHP: Code is not more secure, just because it is closed
> source. I don't think, that any security expert will tell the opposite.
>

Let's see you find detailed instructions on how to build a hydrogen 
bomb.  You won't find it - it's secret.  Never mind that you could never 
do it because you don't have a source of highly enriched uranium or 
plutonium required for the trigger.

Not telling the world how you do something is not "security by 
obfuscation".  But it IS security.

And once again, this is off topic in this newsgroup and will be the last 
I have to say about the subject.


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

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

#4432

Jerry Stuckle, 2012-01-11 20:01:

> On 1/11/2012 12:09 PM, Arno Welzel wrote:
[...]
>> Concerning PHP: Code is not more secure, just because it is closed
>> source. I don't think, that any security expert will tell the opposite.
>>
> 
> Let's see you find detailed instructions on how to build a hydrogen
> bomb.  You won't find it - it's secret.  Never mind that you could never
> do it because you don't have a source of highly enriched uranium or
> plutonium required for the trigger.
> 
> Not telling the world how you do something is not "security by
> obfuscation".  But it IS security.
> 
> And once again, this is off topic in this newsgroup and will be the last
> I have to say about the subject.

Sorry - but *you* mentioned off-topic examples for "security" twice
which have nothing to do with the topic of *PHP*. I never talked about
houses, bombs etc. - just security in *software*.

You claimed, security experts say, closed source is good for security.
If this statement was not about *software*, then your first statement
was already off-topic.

To get back to the topic: Magic Quotes was also an attempt to make PHP
scripts more secure by avoiding SQL injection. Unfortunately in the
early days of PHP the people behind PHP seemed to know little about
security and PHP was never meant as a powerful universal language for
web applications. Now we have still to deal with many of those
historical attempts to be "secure" like safe mode, Magic Quotes etc. -
but you must be aware, that PHP is not secure by design.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#4232

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.

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

#4236

On 1/6/2012 11:41 AM, M. Strobel wrote:
> Am 06.01.2012 01:36, schrieb Jerry Stuckle:
>> On 1/5/2012 6:28 PM, M. Strobel wrote:
>>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>>
> ------cut
>>
>> $REQUESTS is quite dangerous. You never know whether it comes
>> from $_GET, $_POST or $_COOKIE, for instance.
>
> Why do you need to know exactly if the data is from GET or POST?
> Does your program use POST urls with variables in the url?
>
> If yes, did you not take care to have different variable names?
>
> I know one thing: the data comes from the user.
>
>> A hacker can easily manipulate things like $_COOKIE to put
>> whatever he wants in them.  Rather, you should use $_GET, $_POST
>> and $_COOKIE, as appropriate.  Additionally, what you actually
>> get depends on the request_order option in the php.ini file, and
>> can change - potentially breaking your code.
>>
>
> Why mention cookie here? He can manipulate everything.
>
> I taught an interface programmer how to test my forms with curl,
> see here http://curl.haxx.se/docs/manpage.html especially the
> --get and --form options.
>
> $_REQUEST is not more dangerous than programming in PHP. q.e.d.
>
> /Str.

Keep thinking that.  Those of us concerned about security will keep 
using the appropriate values.

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

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

#4228

On 1/6/2012 12:28 AM, M. Strobel wrote:
> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>
>> And $_REQUEST should be avoided anyway in all situation (in my
>> humble opinion) for various reasons. But if you use it, it should
>> indeed be added to your list in your approach.
>>
>> Regards,
>> Erwin Moller
>
> For me $_REQUEST is quite handy. All my functions reading user
> input use this. So they work equally well on different requests.

Hi Strobel,

And why do you prefer $_REQUEST over using the exact superglobal?
You do know where the information is supposed to come from.


>
> But then I have to mention my setup with a sort of call
> dispatcher: the called function is looked up in a list taking
> into account $_SERVER['REQUEST_METHOD'].

That explanation makes no sense to me without any more context.
Are you saying you are limiting access to certain function by checking 
the used $_SERVER['REQUEST_METHOD']?
If so, that won't help at all, since anybody could still use the "right" 
REQUEST_METHOD and manipulate the contents of GPC at the same time.


>
> All user input must be verified, no matter if it's in $_GET,
> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
> faked!

Of course.
But how does that relate to using $_REQUEST over the exact superglobal?

>
> Do not think that only your forms will be sent to your program.
>
> /Str.

I still see no reason at all to use $_REQUEST. It strikes me as lazy and 
dangerous.
Of course you can program right and safe using $_REQUEST only, but it is 
harder. On all occasion you have to wonder if the information you get 
presented came from the place you expected it to come from.
Ans since there is no trade-off (no advantage in using $_REQUEST over 
the exact superglobal) I don't see why you use it.

Often people who use it (in my experience) use $_REQUEST because they 
never bothered to understand how and what information is send around.
Hence they had a poor understanding of what they are doing.
I am not saying you don't understand. I just cannot think of any valid 
reason to use $_REQUEST.

In my opinion $_REQUEST is a design mistake by the PHP developers, just 
like magic_quotes. :-)

If you think I am wrong about that, please tell me why.
I had this discussion a few years back too, but the guy turned out to be 
a troll (and silly me took the bait!), so that turned out to be a dead end.

I am curious what the advantages or $_REQUEST are in your opinion.

In a few exceptional cases where I do expect the info coming from POST 
or GET and cannot tell which one, I simply use something like:

$thing = (
  (isset($_GET["thingy"]))?$_GET["thingy"]:
   (isset($_POST["thingy"])?$_POST["thingy"]:"not set")
);

which is a bit awkward.
But since I almost always know where my data comes from, I don't mind 
such a contraption once in a while. :-)


Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#4233

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.

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

#4237

On 1/6/2012 12:05 PM, M. Strobel wrote:
> Am 06.01.2012 11:07, schrieb Erwin Moller:
>> On 1/6/2012 12:28 AM, M. Strobel wrote:
>>> Am 05.01.2012 14:08, schrieb Erwin Moller:
>>>>
>
> -----------cut on various places
>
>> Hi Strobel,
>>
>> And why do you prefer $_REQUEST over using the exact superglobal?
>> You do know where the information is supposed to come from.
>>
> Yes I know that exactly. But why care? When I expect data I do
>
> function getIntFromForm($key, $def=null) {
>      if (isset($_REQUEST[$key])) {
>          if ($a = sscanf($_REQUEST[$key], '%d')) {   // unsigned
>              $def = $a[0];
>          } else {
>              # keine Zahl im Wert $key / no number
>          }
>      } else {
>          # key nicht gefunden / no key
>      }
>      return $def;
> }
>
>>
>>>
>>> But then I have to mention my setup with a sort of call
>>> dispatcher: the called function is looked up in a list taking
>>> into account $_SERVER['REQUEST_METHOD'].
>>
>> That explanation makes no sense to me without any more context.
>> Are you saying you are limiting access to certain function by
>> checking the used $_SERVER['REQUEST_METHOD']?
>> If so, that won't help at all, since anybody could still use the
>> "right" REQUEST_METHOD and manipulate the contents of GPC at the
>> same time.
>
> This is correct, it is not a real protection, but part of the
> request processing. And the correct request processing takes care
> to only read in and verify expected data.
>
>>>
>>> All user input must be verified, no matter if it's in $_GET,
>>> $_POST, $_COOKIE or $_REQUEST for that matter - they can all be
>>> faked!
>>
>> Of course.
>> But how does that relate to using $_REQUEST over the exact
>> superglobal?
>
> if (is-a-post-operation AND data-expected)
>     read post data;
> elseif (is-a-get-operation AND data-expected)
>     read get data;
>
> What for? Just do
> if (data-expected)  read request data.
>
>
>> If you think I am wrong about that, please tell me why.
>> I had this discussion a few years back too, but the guy turned
>> out to be a troll (and silly me took the bait!), so that turned
>> out to be a dead end.
>
> Always check data on input :-)
>
>>
>> Regards,
>> Erwin Moller
>>
>
> /Str.

You should KNOW whether it is a GET or POST operation, and not allow 
hackers to slip things in other ways.

Of course, when you don't care about your sites being hacked, you can do 
anything you want.

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

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

#4238

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.

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

#4243

On 1/6/2012 1:45 PM, M. Strobel wrote:
> Am 06.01.2012 19:07, schrieb Jerry Stuckle:
>> You should KNOW whether it is a GET or POST operation, and not
>> allow hackers to slip things in other ways.
>>
>
> I never said I do not know if it's a GET or POST operation. On
> the contrary.
>
>> Of course, when you don't care about your sites being hacked, you
>> can do anything you want.
>>
> Repetitive.
>
> You did not pick up this:
>
> Why do you need to know exactly if the data is from GET or POST?
> Does your program use POST urls with variables in the url?
>
> If yes, did you not take care to have different variable names?
>
> /Str.

Because I only allow POST operations on specific pages and GET 
operations on others.  And I do not allow values from one type operation 
to be mixed with values of the other, or with cookies.

But then I care about security.

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

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

#4262

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

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

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

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

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

csiph-web