| Re: Magic quotes? Should I still be cautious? [message #176453 is a reply to message #176437] |
Sat, 07 January 2012 16:59   |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176455 is a reply to message #176436] |
Sat, 07 January 2012 17:08 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176462 is a reply to message #176453] |
Sat, 07 January 2012 20:54 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176464 is a reply to message #176455] |
Sat, 07 January 2012 20:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/7/2012 12:08 PM, Thomas Mlynarczyk wrote:
> 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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176469 is a reply to message #176462] |
Sun, 08 January 2012 01:13 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176470 is a reply to message #176469] |
Sun, 08 January 2012 01:33 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176508 is a reply to message #176427] |
Sun, 08 January 2012 19:48 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176509 is a reply to message #176437] |
Sun, 08 January 2012 19:52 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176512 is a reply to message #176509] |
Sun, 08 January 2012 20:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176520 is a reply to message #176470] |
Sun, 08 January 2012 23:21 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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)
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176524 is a reply to message #176520] |
Mon, 09 January 2012 00:05 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176607 is a reply to message #176606] |
Wed, 11 January 2012 11:53 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
>
>
>
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176610 is a reply to message #176606] |
Wed, 11 January 2012 13:44 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176611 is a reply to message #176607] |
Wed, 11 January 2012 13:45 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176613 is a reply to message #176607] |
Wed, 11 January 2012 14:43 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176614 is a reply to message #176610] |
Wed, 11 January 2012 14:47 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176615 is a reply to message #176614] |
Wed, 11 January 2012 14:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176617 is a reply to message #176615] |
Wed, 11 January 2012 17:09 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176619 is a reply to message #176617] |
Wed, 11 January 2012 19:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Magic quotes? Should I still be cautious? [message #176623 is a reply to message #176619] |
Thu, 12 January 2012 07:58 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]