I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive php programmers working on my server introduced
this security flaw in separate web pages. As the third bit of
evidence, I point out that crackers have created security tools
designed specifically to exploit this flaw.
This security flaw is common.
I'm aware that it's possible to write php code that uses the current
include securely manner. I'm aware that it's possible to turn off
this functionality. I'm aware that it's possible to run php in a more
secure manner.
The evidence presented above says that none of those possibilities are
pursued often enough. It's possible that they could be encouraged
more. I suggest instead that 'include' as designed is intrinsically
harmful. It's an attractive nuisance.
I suggest that its functionality should be split into two operators.
One of these operators is still called 'include' and behaves the way
that naive PHP programmers believe it behaves: it only includes files
taken from the local file system. It doesn't include any files with
two consecutive dots, and it doesn't include any file beginning with
slash. In other words, it can only be used to include files at or
below the current directory.
Another operator (which I would call 'includeremotesecurityhole', but
you can call it what you will) behaves the way the current php
operator behaves. If so instructed, it will fetch remote hostile
content and execute it with local privileges.
FAQs:
Q: Are you stupid?
A: Not particularly. Stupidity and ignorance are not the same thing.
Q: If you're that ignorant, you got what you deserve.
A: Actually, there are many things of which I'm ignorant, and I
deserve no harm from any of the other things.
Q: Why did you allow these programmers to write such code?
A: Because I thought PHP didn't have such huge gaping security flaws.
Q: PHP doesn't have those flaws; the programmers put it in.
A: If that's the case, then why do so many programmers put it in?
Q: All other systems have the same problems: .ASP, .NET, etc.
A: And those are quality targets to shoot for?
Q: Do you hate PHP?
A: No, I love PHP! It allows naive programmers to be amazingly
productive.
Q: If you hate PHP so much, just turn it off.
A: But PHP allows naive programmers to be amazingly productive.
Q: Did you read the documentation? It clearly explains the risks.
A: The documentation is the wrong place to fix this problem.
Q: Did you turn off the remote-fetching, local-executing feature?
A: The configuration is the wrong place to fix this problem.
Q: 'include' works just fine; why do you want to change it?
A: Because it creates the wrong expectation in programmers new to
PHP. If the operator had the same semantics but the name
'includeremotesecurityhole' programmers would change their
expectations of the operator. Hazardous equipment will have yellow
markings on it precisely because the equipment doesn't look
dangerous. A saw blade doesn't need yellow markings because it
is what it appears to be: extremely sharp and dangerous.
Q: Do you know how much code this change will break?
A: No. Do you know how much insecure code is out there waiting to be
found and exploited, which this change will make secure?
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
Hmm.. If anything, E_STRICT could leave a warning about variables being used
with include/require.. This is the PHP programmers fault clearly.. And the
documentation is exactly the right place.. Your suggestion is pretty much as
stupid as suggesting to forbid ../ in fopen().. There's nothing wrong with
PHP, it's definitly the PHP programmers fault.. It does exactly what I
expect it to do, and afaik, what most people expect it to do.. If they write
code to include unchecked GET/POST vars, then they don't write code with
security in mind at all..
nelson-lists@crynwr.com skrev i meddelandet
news:20050624055017.25065.qmail@desk.crynwr.com...
I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive php programmers working on my server introduced
this security flaw in separate web pages. As the third bit of
evidence, I point out that crackers have created security tools
designed specifically to exploit this flaw.This security flaw is common.
I'm aware that it's possible to write php code that uses the current
include securely manner. I'm aware that it's possible to turn off
this functionality. I'm aware that it's possible to run php in a more
secure manner.The evidence presented above says that none of those possibilities are
pursued often enough. It's possible that they could be encouraged
more. I suggest instead that 'include' as designed is intrinsically
harmful. It's an attractive nuisance.I suggest that its functionality should be split into two operators.
One of these operators is still called 'include' and behaves the way
that naive PHP programmers believe it behaves: it only includes files
taken from the local file system. It doesn't include any files with
two consecutive dots, and it doesn't include any file beginning with
slash. In other words, it can only be used to include files at or
below the current directory.Another operator (which I would call 'includeremotesecurityhole', but
you can call it what you will) behaves the way the current php
operator behaves. If so instructed, it will fetch remote hostile
content and execute it with local privileges.FAQs:
Q: Are you stupid?
A: Not particularly. Stupidity and ignorance are not the same thing.Q: If you're that ignorant, you got what you deserve.
A: Actually, there are many things of which I'm ignorant, and I
deserve no harm from any of the other things.Q: Why did you allow these programmers to write such code?
A: Because I thought PHP didn't have such huge gaping security flaws.Q: PHP doesn't have those flaws; the programmers put it in.
A: If that's the case, then why do so many programmers put it in?Q: All other systems have the same problems: .ASP, .NET, etc.
A: And those are quality targets to shoot for?Q: Do you hate PHP?
A: No, I love PHP! It allows naive programmers to be amazingly
productive.Q: If you hate PHP so much, just turn it off.
A: But PHP allows naive programmers to be amazingly productive.Q: Did you read the documentation? It clearly explains the risks.
A: The documentation is the wrong place to fix this problem.Q: Did you turn off the remote-fetching, local-executing feature?
A: The configuration is the wrong place to fix this problem.Q: 'include' works just fine; why do you want to change it?
A: Because it creates the wrong expectation in programmers new to
PHP. If the operator had the same semantics but the name
'includeremotesecurityhole' programmers would change their
expectations of the operator. Hazardous equipment will have yellow
markings on it precisely because the equipment doesn't look
dangerous. A saw blade doesn't need yellow markings because it
is what it appears to be: extremely sharp and dangerous.Q: Do you know how much code this change will break?
A: No. Do you know how much insecure code is out there waiting to be
found and exploited, which this change will make secure?--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
This has been discussed very much long ago. I use variables in include
clauses and always take a very special attention at it. Adding a
warning in E_STRICT does not make any sense either. In no way PHP can
judge if the instruction is needed or not. I, for myself, code in
E_STRICT and don't deserve any supplementary warnings. Correctly using
the include clause is the programmer's responsability.
Keep one thing in mind: PHP is not a babysitter.
Hmm.. If anything,
E_STRICTcould leave a warning about variables being used
with include/require.. This is the PHP programmers fault clearly.. And the
documentation is exactly the right place.. Your suggestion is pretty much as
stupid as suggesting to forbid ../ infopen().. There's nothing wrong with
PHP, it's definitly the PHP programmers fault.. It does exactly what I
expect it to do, and afaik, what most people expect it to do.. If they write
code to include unchecked GET/POST vars, then they don't write code with
security in mind at all..nelson-lists@crynwr.com skrev i meddelandet
news:20050624055017.25065.qmail@desk.crynwr.com...I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive php programmers working on my server introduced
this security flaw in separate web pages. As the third bit of
evidence, I point out that crackers have created security tools
designed specifically to exploit this flaw.This security flaw is common.
I'm aware that it's possible to write php code that uses the current
include securely manner. I'm aware that it's possible to turn off
this functionality. I'm aware that it's possible to run php in a more
secure manner.The evidence presented above says that none of those possibilities are
pursued often enough. It's possible that they could be encouraged
more. I suggest instead that 'include' as designed is intrinsically
harmful. It's an attractive nuisance.I suggest that its functionality should be split into two operators.
One of these operators is still called 'include' and behaves the way
that naive PHP programmers believe it behaves: it only includes files
taken from the local file system. It doesn't include any files with
two consecutive dots, and it doesn't include any file beginning with
slash. In other words, it can only be used to include files at or
below the current directory.Another operator (which I would call 'includeremotesecurityhole', but
you can call it what you will) behaves the way the current php
operator behaves. If so instructed, it will fetch remote hostile
content and execute it with local privileges.FAQs:
Q: Are you stupid?
A: Not particularly. Stupidity and ignorance are not the same thing.Q: If you're that ignorant, you got what you deserve.
A: Actually, there are many things of which I'm ignorant, and I
deserve no harm from any of the other things.Q: Why did you allow these programmers to write such code?
A: Because I thought PHP didn't have such huge gaping security flaws.Q: PHP doesn't have those flaws; the programmers put it in.
A: If that's the case, then why do so many programmers put it in?Q: All other systems have the same problems: .ASP, .NET, etc.
A: And those are quality targets to shoot for?Q: Do you hate PHP?
A: No, I love PHP! It allows naive programmers to be amazingly
productive.Q: If you hate PHP so much, just turn it off.
A: But PHP allows naive programmers to be amazingly productive.Q: Did you read the documentation? It clearly explains the risks.
A: The documentation is the wrong place to fix this problem.Q: Did you turn off the remote-fetching, local-executing feature?
A: The configuration is the wrong place to fix this problem.Q: 'include' works just fine; why do you want to change it?
A: Because it creates the wrong expectation in programmers new to
PHP. If the operator had the same semantics but the name
'includeremotesecurityhole' programmers would change their
expectations of the operator. Hazardous equipment will have yellow
markings on it precisely because the equipment doesn't look
dangerous. A saw blade doesn't need yellow markings because it
is what it appears to be: extremely sharp and dangerous.Q: Do you know how much code this change will break?
A: No. Do you know how much insecure code is out there waiting to be
found and exploited, which this change will make secure?--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.--
--
Nicolas Bérard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).
Nicolas Bérard Nault writes:
Correctly using the include clause is the programmer's responsability.
And yet ... I keep going back to the fact that people don't use it
correctly. It's a fact that many people use 'include' incorrectly.
If you say that the people are wrong, then you are asking people to
modify their behavior to match the computer's design. Shouldn't we be
modifying the computer's design to match people's expectations?
Have you ever gone to a carnival and seen the trick bicycle booth?
They've made up a bicycle which steers backwards using an extra gear.
If you turn left, the bicycle goes right. You can pay to try to ride
the bicycle ten feet. The booth operator has modified his behavior,
and knows how to ride it. He makes it look easy. Nobody else can
ride it even ten feet because the bicycle has been designed
specifically to operate counter to people's expectations.
There is plenty of evidence that 'include' operates counter to
people's expectations. Use of 'include' to include off-host content
should be deprecated in the next release, and removed in the release
afterwards, in favor of 'includeremote'.
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
E_STRICT would be a nice place to leave a warning, but of course, the naive
programmers don't use E_STRICT, so what's the point in that? Personally, I
think include is just fine the way it is. What I could imagine though, is
that the include() function would be enhanced with parameters to
allow/disallow the inclusion of remote files and files in parent dirs... but
I don't see the point, and it would suddenly create an unwanted difference
between the include construct and the include function...
Nah, if it were up to me, we'd leave include just the way it is....
Ron
""DvDmanDT"" dvdmandt@telia.com wrote in message
news:04.19.22648.2895CB24@pb1.pair.com...
Hmm.. If anything,
E_STRICTcould leave a warning about variables being
used
with include/require.. This is the PHP programmers fault clearly.. And the
documentation is exactly the right place.. Your suggestion is pretty much
as
stupid as suggesting to forbid ../ infopen().. There's nothing wrong with
PHP, it's definitly the PHP programmers fault.. It does exactly what I
expect it to do, and afaik, what most people expect it to do.. If they
write
code to include unchecked GET/POST vars, then they don't write code with
security in mind at all..nelson-lists@crynwr.com skrev i meddelandet
news:20050624055017.25065.qmail@desk.crynwr.com...I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive php programmers working on my server introduced
this security flaw in separate web pages. As the third bit of
evidence, I point out that crackers have created security tools
designed specifically to exploit this flaw.This security flaw is common.
I'm aware that it's possible to write php code that uses the current
include securely manner. I'm aware that it's possible to turn off
this functionality. I'm aware that it's possible to run php in a more
secure manner.The evidence presented above says that none of those possibilities are
pursued often enough. It's possible that they could be encouraged
more. I suggest instead that 'include' as designed is intrinsically
harmful. It's an attractive nuisance.I suggest that its functionality should be split into two operators.
One of these operators is still called 'include' and behaves the way
that naive PHP programmers believe it behaves: it only includes files
taken from the local file system. It doesn't include any files with
two consecutive dots, and it doesn't include any file beginning with
slash. In other words, it can only be used to include files at or
below the current directory.Another operator (which I would call 'includeremotesecurityhole', but
you can call it what you will) behaves the way the current php
operator behaves. If so instructed, it will fetch remote hostile
content and execute it with local privileges.FAQs:
Q: Are you stupid?
A: Not particularly. Stupidity and ignorance are not the same thing.Q: If you're that ignorant, you got what you deserve.
A: Actually, there are many things of which I'm ignorant, and I
deserve no harm from any of the other things.Q: Why did you allow these programmers to write such code?
A: Because I thought PHP didn't have such huge gaping security flaws.Q: PHP doesn't have those flaws; the programmers put it in.
A: If that's the case, then why do so many programmers put it in?Q: All other systems have the same problems: .ASP, .NET, etc.
A: And those are quality targets to shoot for?Q: Do you hate PHP?
A: No, I love PHP! It allows naive programmers to be amazingly
productive.Q: If you hate PHP so much, just turn it off.
A: But PHP allows naive programmers to be amazingly productive.Q: Did you read the documentation? It clearly explains the risks.
A: The documentation is the wrong place to fix this problem.Q: Did you turn off the remote-fetching, local-executing feature?
A: The configuration is the wrong place to fix this problem.Q: 'include' works just fine; why do you want to change it?
A: Because it creates the wrong expectation in programmers new to
PHP. If the operator had the same semantics but the name
'includeremotesecurityhole' programmers would change their
expectations of the operator. Hazardous equipment will have yellow
markings on it precisely because the equipment doesn't look
dangerous. A saw blade doesn't need yellow markings because it
is what it appears to be: extremely sharp and dangerous.Q: Do you know how much code this change will break?
A: No. Do you know how much insecure code is out there waiting to be
found and exploited, which this change will make secure?--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
Ron Korving writes:
Personally, I think include is just fine the way it is.
Google for "php security flaw". Do you think that's fine the way it
is?
Clearly, the fact that you can turn this behavior off suggests that
somebody has noticed that it's badly designed. Rather than say, as
some people have, "Well, just turn it off if you don't like it" or
"Well, program around it by checking your data" or "php isn't a
babysitter", it would be better to fix the flaw in the language that
requires the flag to turn off the misdesigned behavior.
If the very first thing you have to do with a language feature is make
sure that it doesn't function as designed (which is to execute hostile
content with local privileges), then clearly the design of that
feature is wrong.
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
If the very first thing you have to do with a language feature is make
sure that it doesn't function as designed (which is to execute hostile
content with local privileges), then clearly the design of that
feature is wrong.
Or the default value of the configuration setting has been a bad choice?
Maybe that's it?
Ron
Quoted Text:
In other words, it can only be used to include files at or below the
current directory.
This is counter productive, it is a horrible idea to store include
files within (/below) the document root, if you're going to suggest
strange sweeping changes go the reverse direction, ensure that any
include'd files are outside the document root (though possibly on the
local server).
paul
Why not simply disable allow_url_fopen on your server or servers? With
it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
server configuration in .../test.php on line 3
Warning: main(http://www.google.com/) [function.main]: failed to open
stream: no suitable wrapper could be found in .../test.php on line 3
Warning: main() [function.include]: Failed opening
'http://www.google.com/' for inclusion (include_path='.') in
.../test.php on line 3
Now, yes, some scripts work better with that setting on, but it is the
setting to disable if you're worried about naive programmers. You can
even allow them to turn it back on with Apache's .htaccess.
-[Unknown]
I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive php programmers working on my server introduced
this security flaw in separate web pages. As the third bit of
evidence, I point out that crackers have created security tools
designed specifically to exploit this flaw.
Unknown W. Brackets writes:
Why not simply disable allow_url_fopen on your server or servers?
Why don't people do that? Obviously ... they don't.
If you have no other answer than "Maybe they don't care about
security, maybe they're stupid, maybe they're native", then may I
suggest that the problem is intrinsic to 'include'?
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.