Avoid 'every remote exploit' - is that possible?

[Jake Lloyd]

In "A Note on Security In PHP" (partly in reference to a security flaw
that exists or recently did exist in phpBB) at
http://nl3.php.net/security-note.php
The PHP Group makes this claim:
"Every remote exploit can be avoided with very careful input validation."
This is very reassuring, if it is true, and it gives much to be said in
favor of implementing PHP in applications that accept remote user input.
But is it true?
One rarely sees an unqualified claim that any mechanism can provide
protection against every exploit, of any kind.
I wonder whether anyone who as read this Note on Security in PHP has
good reason to doubt this categorical claim over the capacity of
well-implemented input validation (using PHP) to "avoid every remote
exploit..."
I'm interested in any expressed view, supporting or refuting this claim.
- Jake Lloyd

[NSpam]

Jake Lloyd wrote:

In "A Note on Security In PHP" (partly in reference to a security flaw
that exists or recently did exist in phpBB) at
http://nl3.php.net/security-note.php
The PHP Group makes this claim:
"Every remote exploit can be avoided with very careful input validation."
This is very reassuring, if it is true, and it gives much to be said in
favor of implementing PHP in applications that accept remote user input.
But is it true?
One rarely sees an unqualified claim that any mechanism can provide
protection against every exploit, of any kind.
I wonder whether anyone who as read this Note on Security in PHP has
good reason to doubt this categorical claim over the capacity of
well-implemented input validation (using PHP) to "avoid every remote
exploit..."
I'm interested in any expressed view, supporting or refuting this claim.
- Jake Lloyd

Ho hum, anyone saying never is on a hiding to nothing.

It is possible to protect a website that employs PHP but it needs to be
done in conjunction with a security mindset.

Much of the protection needs to be at the Operating System level. Above
that think of firewalls. A concept that I find useful is that of an
onion sliced in half - don't laugh too much. Slice an onion in half and
one sees a series of concentric rings. Each of the rings maps to a level
of security.

With regard to PHP i think the quote is justified. Defensive coding is a
mindset that requires a "what if" type attitude. Unfortunately there are
a lot of mindless hooligans who enjoy finding security holes in systems.
I don't think this is neccesarily a bad practice as long as damage is
not caused to data.

Unfortunately many people developing websites do not have the technical
knowledge or the ability to engage with the concept of asynchronous
environments. Security problems reside within PHP code as the coders do
not consider the "what if" issues that arise.
Chris

[NSpam]

NSpam wrote:

Jake Lloyd wrote:

In "A Note on Security In PHP" (partly in reference to a security flaw
that exists or recently did exist in phpBB) at
http://nl3.php.net/security-note.php
The PHP Group makes this claim:
"Every remote exploit can be avoided with very careful input validation."
This is very reassuring, if it is true, and it gives much to be said
in favor of implementing PHP in applications that accept remote user
input.
But is it true?
One rarely sees an unqualified claim that any mechanism can provide
protection against every exploit, of any kind.
I wonder whether anyone who as read this Note on Security in PHP has
good reason to doubt this categorical claim over the capacity of
well-implemented input validation (using PHP) to "avoid every remote
exploit..."
I'm interested in any expressed view, supporting or refuting this claim.
- Jake Lloyd

Ho hum, anyone saying never is on a hiding to nothing.

It is possible to protect a website that employs PHP but it needs to be
done in conjunction with a security mindset.

Much of the protection needs to be at the Operating System level. Above
that think of firewalls. A concept that I find useful is that of an
onion sliced in half - don't laugh too much. Slice an onion in half and
one sees a series of concentric rings. Each of the rings maps to a level
of security.

With regard to PHP i think the quote is justified. Defensive coding is a
mindset that requires a "what if" type attitude. Unfortunately there are
a lot of mindless hooligans who enjoy finding security holes in systems.
I don't think this is neccesarily a bad practice as long as damage is
not caused to data.

Unfortunately many people developing websites do not have the technical
knowledge or the ability to engage with the concept of asynchronous
environments. Security problems reside within PHP code as the coders do
not consider the "what if" issues that arise.
Chris

Most of the security problems associated with PHP are a result of sloppy
coding and unitialised variables. The sort of thing that a compliler
catches.

PHP like most scripting languages performs an implicit variable creation
if the referenced item does not exist.

Thus in C or any other strongly type language

x = 1;

result - compiler error with undefined variable

PHP

$x =1;

no problem

where the sloppiness comes in with PHP is when using GET and POST
content coupled with auto allocation of a symbol.

Effectively, one has to do the job of a compiler in the PHP source to
ensure that you know exactly where the content of the variable was
derived from.

[ZeldorBlat]

where the sloppiness comes in with PHP is when using GET and POST
content coupled with auto allocation of a symbol.

A great example of this (and a common PHP coding error) occurs when
using session variables with register globals enabled. For example, if
users succesfully login and you have a session variable called
"authorized," you might say at the top of each page:

if($authorized == false)
//redirect to the login page

But if someone goes to any page and adds ?authorized=1 to the end of
the URL, they can bypass the login. Register globals registers GET and
POST variables in the global scope, and, by default, get registered
after session variables. In other words, if you have GET or POST
variables by the same name as a session variable, the GET or POST
variables will overwrite the session variable (although this order can
be changed in php.ini).

It's important to note that it isn't register globals by itself that
enables this, but rather the complacency that it allows programmers to
get away with. The safer route is to use $_SESSION['authorized']
instead. That will work with register globals enabled or disabled, but
disabling it forces you to use the $_ global variables instead. This
in turn guarantees that you know where the data came from.

[Chung Leong]

"Jake Lloyd" <le******@acm.org> wrote in message
news:42***********************@news.wanadoo.fr...

In "A Note on Security In PHP" (partly in reference to a security flaw
that exists or recently did exist in phpBB) at
http://nl3.php.net/security-note.php
The PHP Group makes this claim:
"Every remote exploit can be avoided with very careful input validation."
This is very reassuring, if it is true, and it gives much to be said in
favor of implementing PHP in applications that accept remote user input.
But is it true?

That's a gross simplication of course. What they mean is "Every remote
exploit involving invalid input can be avoid with very careful input
validation." Other types of exploits, naturally enough, requires other
prevention methods.