This has just appeared:
http://www.theregister.co.uk/2007/01/11/php_apps_security/
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
Alain Williams wrote:
This has just appeared:
There are some concrete suggestions in the article that we addressed a
while ago. Things like:
"I'd like to see new defaults that limit include() and require() to
only allow local files, thereby avoiding remote file injection."
That's the default in PHP 5.2.0 which was released over 2 months ago now.
"It would be nice to have a global way for a script to ignore all
variables in the URL, avoiding unexpected variable manipulation and
XSS forgeries."
We can't really make that the default (which isn't suggested) since that
would break a lot of stuff, but is has been possible to do this for
years by simply removing "G" from the variables_order setting.
"Maybe there's even a way to force users to filter input and escape
output every time, helping to avoid SQL injection and all sorts of
other common problems. That last one would go a long way."
The filter extension has been available for quite a while now in pecl
and is bundled with PHP 5.2 and it does exactly this.
I won't disagree that we can and should do more to help people write
safer apps, but we have to balance that with the ease of use that
brought people to PHP in the first place along with the massive amount
of existing code out there. It is an interesting balancing act.
Another thing to keep in mind is that there are two very distinct
security issues here. Remote vs. Local issues. Just about every
reported security problem against PHP itself has been of the Local
variety. That means that it is a flaw in our various attempts to
separate users that share the same server in a shared hosting
environment. I wrote about this back in 2004 in this note related to
the PHPBB issues at the time:
http://www.php.net/security-note.php
Like I said there, when you share a server with someone else, you are
never going to achieve 100% security against those other local users,
especially if the ISP is running everyone on the same Apache instance
with the same user id, etc. But even with jails/chroot there have been
some interesting ways over the years to defeat those, and I don't doubt
there will be more. Same goes for local PHP issues. It is very hard to
protect the user from himself without completely crippling the language
and the various attempts we have made over the years like safe_mode and
open_basedir can never be fully secure. Something like open_basedir is
however useful as one layer in a layered security model. For example,
you can do an initial layer of user input filtering using something like
mod_security, then further filter using the filter extension and finally
use open_basedir to define a restricted set of directories that an
application should be able to open files from. Any one of those 3
layers may not be 100% secure by themselves, but the chances are pretty
good that in combination it would be quite hard for something nasty to
get through since the holes in each would have to line up perfectly.
An example would be naiive code like this:
readfile("/some/path/".$_GET['filename']);
Assuming the developer didn't think about input filtering at all,
someone could simply put: ?filename=../../etc/passwd
in the URL and they would see the local /etc/passwd file from the
server. Even with shadow passwords on most systems today, it is a bad
idea to allow remote users to read any file on your server.
In this case you could have a mod_security rule to disallow ../.. style
patterns in URLs. But if someone found a way to still sneak that
pattern through, perhaps because of a bug in mod_security related to
weird and wonderful character set tricks, if the application had a
well-defined open_basedir setting the readfile() call would fail trying
to read anything from /etc
A second example:
<a href="/download.php?filename=<?php echo $_GET['filename']?>">download</a>
Again, a very common type of mistake. Without any sort of input
filtering the remote user can do something like:
?filename=/etc/passwd"onmouseover="alert(document.cookie)
Here the bad guy is trying to do 2 attacks at once. It is trying to
trick the download.php script into downloading /etc/passwd and it is
doing a very common XSS attack. Going through our layers we might have
a mod_security rule that tries to strip out tags, but in this case since
there are no tags and we are simply adding an attribute to an existing
tag, it might slip through. Next, ext/filter kicks in with a default
filter of "special_chars" for example and changes " to " and the
XSS is defeated and finally open_basedir stops the /etc/passwd access.
This would all be without changing a single line of code in the
obviously badly written application. Just a couple of configuration
options in Apache and PHP.
Of course, such default filtering and strict open_basedir settings might
break the app if it is expecting unfiltered input somewhere in it or it
is expecting access to a dir you haven't added to your open_basedir
list, but it becomes pretty easy to identify the few places in an app
where you need to loosen things a bit simply by starting off very strict
and seeing where things break.
I hope this explains some of our current thinking towards PHP security.
I really don't think things are as bad as people make them out to be,
but it is all about perception, so if they think it is bad, it is bad
and we need to do a better job documenting things like the filter
extension and how to apply a layered security model in PHP.
-Rasmus
Hello Rasmus,
There are some concrete suggestions in the article that we addressed a
while ago. Things like:"I'd like to see new defaults that limit include() and require() to
only allow local files, thereby avoiding remote file injection."That's the default in PHP 5.2.0 which was released over 2 months ago now.
This is not true. It was demonstrated several times that the
"protection" is easily bypassed by using data:// or php://input URLs.
Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it
certainly is no protection at all when someone can just use one of the
other URL wrappers of PHP that are considered safe and put in an
overlong URL that produces a stack overflow. (Hello zip://)
Another thing to keep in mind is that there are two very distinct
security issues here. Remote vs. Local issues. Just about every
reported security problem against PHP itself has been of the Local
variety. That means that it is a flaw in our various attempts to
What a blatant lie. PHP had several bufferoverflows etc... in functions
often exposed to user input and some direct remote exploits in the past.
To just name a few: htmlentities() overflow, about a million bugs in
unserialize(), fileupload exploits, memory_limit exploits, ... Last year
there was f.e. the zend_hash_del_key_or_index vulnerability that exposed
a large number of PHP applications to remote attacks. Ah yes and If I
had not babysitted the CVS in the past there would be even more direct
remote exploits against PHP, like the HTTP Digest Auth double free
vulnerability. And yes, only looking at local holes, PHP has more than
enough of them.
In this case you could have a mod_security rule to disallow ../.. style
patterns in URLs. But if someone found a way to still sneak that
pattern through, perhaps because of a bug in mod_security related to
There is nothing more trivial than sneaking something through the
combination mod_security + PHP.
tag, it might slip through. Next, ext/filter kicks in with a default
filter of "special_chars" for example and changes " to " and the
Maybe, if ext/filter would be bug free...
Stefan Esser
PS: Stop the "We are secure" marketing and face reality
Stefan Esser wrote:
Hello Rasmus,
There are some concrete suggestions in the article that we addressed a
while ago. Things like:"I'd like to see new defaults that limit include() and require() to
only allow local files, thereby avoiding remote file injection."That's the default in PHP 5.2.0 which was released over 2 months ago now.
This is not true. It was demonstrated several times that the
"protection" is easily bypassed by using data:// or php://input URLs.
Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it
certainly is no protection at all when someone can just use one of the
other URL wrappers of PHP that are considered safe and put in an
overlong URL that produces a stack overflow. (Hello zip://)
Yes, this has been fixed. And I didn't say it was bug free. Nothing is
ever bug free, but that the feature was introduced.
Another thing to keep in mind is that there are two very distinct
security issues here. Remote vs. Local issues. Just about every
reported security problem against PHP itself has been of the Local
variety. That means that it is a flaw in our various attempts toWhat a blatant lie. PHP had several bufferoverflows etc... in functions
often exposed to user input and some direct remote exploits in the past.
To just name a few:htmlentities()overflow, about a million bugs in
unserialize(), fileupload exploits, memory_limit exploits, ... Last year
there was f.e. the zend_hash_del_key_or_index vulnerability that exposed
a large number of PHP applications to remote attacks. Ah yes and If I
had not babysitted the CVS in the past there would be even more direct
remote exploits against PHP, like the HTTP Digest Auth double free
vulnerability. And yes, only looking at local holes, PHP has more than
enough of them.
Sure, but the majority were still local. Some of the local ones can of
course be triggered remotely given the right circumstances which is why
they are still very important to fix. We fix them as fast as we can and
appreciate any help we get from you and others on this front.
PS: Stop the "We are secure" marketing and face reality
This isn't "we are secure" marketing. This is simply explaining what we
are doing to make PHP more secure.
-Rasmus
Hello Stefan,
Hello Rasmus,
There are some concrete suggestions in the article that we addressed a
while ago. Things like:"I'd like to see new defaults that limit include() and require() to
only allow local files, thereby avoiding remote file injection."That's the default in PHP 5.2.0 which was released over 2 months ago now.
This is not true. It was demonstrated several times that the
"protection" is easily bypassed by using data:// or php://input URLs.
Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it
certainly is no protection at all when someone can just use one of the
other URL wrappers of PHP that are considered safe and put in an
overlong URL that produces a stack overflow. (Hello zip://)
For your information, zip is not enabled by default. If you have a
bug/issue about the specific zip:// URL, please let me know. Ilia and
Tony already fixed some paths fixes and the fixes are available in
zip-1.8.4. They will be in 5.2.1.
--Pierre
For your information, zip is not enabled by default. If you have a
bug/issue about the specific zip:// URL, please let me know. Ilia and
Tony already fixed some paths fixes and the fixes are available in
zip-1.8.4. They will be in 5.2.1.
For your information Pierre: Security Bugs in PHP are usually found by
me. So guess twice WHO told security@php.net that there are
bufferoverflows in zip:// URLs and WHY there have been bugfixes to ext/zip.
BTW: Last time I checked, popular packages like dotdeb PHP activate
ext/zip by default...
And yes... Also prepare for the more than 30 vulnerabilities I
disclosed to security@php.net during the last 3 weeks.
Have fun...
Stefan
Hi Stefan,
For your information, zip is not enabled by default. If you have a
bug/issue about the specific zip:// URL, please let me know. Ilia and
Tony already fixed some paths fixes and the fixes are available in
zip-1.8.4. They will be in 5.2.1.
For your information Pierre: Security Bugs in PHP are usually found by
me. So guess twice WHO told security@php.net that there are
bufferoverflows in zip:// URLs and WHY there have been bugfixes to ext/zip.
No idea who posted them or if someone posted something about zip. As
you know I have no access to security@ and so far all I see are
commits in my packages without much explanations. Not like I do not
want you or anyone else to help or to do not give you the credits. But
I did not know that someone else reported the issues, I apologize for
that.
BTW: Last time I checked, popular packages like dotdeb PHP activate
ext/zip by default...And yes... Also prepare for the more than 30 vulnerabilities I
disclosed to security@php.net during the last 3 weeks.
Nice, better later than never. Remember my numerous requests in the
last months BEFORE the stable release (and you were still a PHP
Securtiy member)?
Have fun...
I have fun anyway, if not I will not bother to discuss that here.
--Pierre
Hi Stefan,
For your information, zip is not enabled by default. If you have a
bug/issue about the specific zip:// URL, please let me know. Ilia and
Tony already fixed some paths fixes and the fixes are available in
zip-1.8.4. They will be in 5.2.1.
For your information Pierre: Security Bugs in PHP are usually found by
me. So guess twice WHO told security@php.net that there are
bufferoverflows in zip:// URLs and WHY there have been bugfixes to ext/zip.No idea who posted them or if someone posted something about zip. As
you know I have no access to security@ and so far all I see are
commits in my packages without much explanations. Not like I do not
want you or anyone else to help or to do not give you the credits. But
I did not know that someone else reported the issues, I apologize for
that.BTW: Last time I checked, popular packages like dotdeb PHP activate
ext/zip by default...And yes... Also prepare for the more than 30 vulnerabilities I
disclosed to security@php.net during the last 3 weeks.Nice, better later than never. Remember my numerous requests in the
last months BEFORE the stable release (and you were still a PHP
Securtiy member)?
After having received the info (Thanks to Rasmus and Ilia), I can say
that only one flaw was related to the active zip extension (zip://
used with huge path). This flaw is already fixed in php-src and the
last PECL release (1.8.4) contains the fix as a release has been done
2 days after I saw the commit. That does not mean there is no other
but that is the only known issue and it is now fixed.
The active branch is available in PECL (latest version is 1.8.4) and
from PHP 5.2.0 or earlier. This extension is 100% backward compatible
with the old API but with a complete new implementation. If any linux
distribution still provides php4 packages, I can only recommend to use
this new version instead of the old and unmaintained code (or even
better, drop php4).
I hope things are clearer now.
--Pierre
PS: Stop the "We are secure" marketing and face reality
More to the point: ''We might be secure because we are careful experienced programmers'',
however many of those who write in PHP are not careful and/or experienced, we should
be looking to help those people - there are more of them than they are of us.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams [addw@phcomp.co.uk] said the following:
PS: Stop the "We are secure" marketing and face reality
More to the point: ''We might be secure because we are careful experienced programmers'',
however many of those who write in PHP are not careful and/or experienced, we should
be looking to help those people - there are more of them than they are of us.
And for the programmers that write programs that require safe mode to
be off or don't provide a provision for having it on. STOP telling your
users things like "If your webhost has safe mode on then they suck".
Safe mode is the only way to get around certain situations. Get a clue.
You know who you are.
Somehow I doubt any of these said programmers are on this list.
Shame.
Mark
--
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/
Safe mode does suck, and it utterly useless anyone who knows PHP
internals will happily tell you that.
On Thu, Jan 11, 2007 at 04:17:31PM GMT, Alain Williams
[addw@phcomp.co.uk] said the following:PS: Stop the "We are secure" marketing and face reality
More to the point: ''We might be secure because we are careful
experienced programmers'',
however many of those who write in PHP are not careful and/or
experienced, we should
be looking to help those people - there are more of them than they
are of us.And for the programmers that write programs that require safe mode to
be off or don't provide a provision for having it on. STOP telling
your
users things like "If your webhost has safe mode on then they suck".
Safe mode is the only way to get around certain situations. Get a
clue.
You know who you are.Somehow I doubt any of these said programmers are on this list.
Shame.Mark
--
Mark S. Krenz
IT Director
Suso Technology Services, Inc.
http://suso.org/--
Ilia Alshanetsky
PS: Stop the "We are secure" marketing and face reality
I wonder what do you mean by that - that PHP group should publish press
release "PHP is not secure, please do not use it anymore" or what? I see
PHP group is working quite well eliminating the security issues. As far
as I know, last year there was 7 remotely exploitable issues in PHP
(which is regrettable but that's the way of life to have bugs), and all
of them are fixed, IIRC, and within acceptable timeframe (the last can
be debatable, but PHP being opesource project the only way to fix it is
to get more participation from people in submitting patches). I know of
no remotely exploitable security issue that is now in current PHP version.
So I wonder what would you like PHP Group to improve? What would you
mean by facing reality - what in your opinion the reality is and what
would you have PHP group to do to satisfy you on facing reality account?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
I wonder what do you mean by that - that PHP group should publish
press release "PHP is not secure, please do not use it anymore" or
what? I see PHP group is working quite well eliminating the security
issues. As far as I know, last year there was 7 remotely exploitable
issues in PHP (which is regrettable but that's the way of life to have
bugs), and all of them are fixed, IIRC, and within acceptable
timeframe (the last can be debatable, but PHP being opesource project
the only way to fix it is to get more participation from people in
submitting patches). I know of no remotely exploitable security issue
that is now in current PHP version.
So I wonder what would you like PHP Group to improve? What would you
mean by facing reality - what in your opinion the reality is and what
would you have PHP group to do to satisfy you on facing reality account?
First of all PHP group is doing nothing. Neither do they improve PHP's
security nor do they stop well known PHP license abusers (because they
are friends).
Secondly security patches are done by Ilia and maybe the Zend stuff by
Dmitry. All the others are doing nothing in the sense of security.
And do I need to remind you about a certain bug in the new super duper
Zend Memory manager that results in a far too small buffer being allocated?
Do I need to post an exploit that uses this bug to exploit for example
the Soap HTTP client from ext/soap? This is a kind of remote exploit
against PHP. And god knows how many other places are vulnerable because
of the new "improved" Zend Memory Manager.
And what about the heap underflow bug in ext/filter... Also not a remote
exploit?
The fact that you do not know about any remote exploit against PHP is
quite irrelevant for reality.
Stefan Esser
This is pathetic. I thought most of you were adults, but I really
can't tell sometimes.
Why can't this be discussed without everyone getting upset and
snapping at each other? The biggest problem with PHP right now is how
thick-headed and cocky some of the posters to this list are. Grow up,
and then maybe PHP will have a chance to grow up.
It's only taken a couple months to realize how much time is wasted on
political crap on this list instead of bug-fixing.
I wonder what do you mean by that - that PHP group should publish
press release "PHP is not secure, please do not use it anymore" or
what? I see PHP group is working quite well eliminating the security
issues. As far as I know, last year there was 7 remotely exploitable
issues in PHP (which is regrettable but that's the way of life to have
bugs), and all of them are fixed, IIRC, and within acceptable
timeframe (the last can be debatable, but PHP being opesource project
the only way to fix it is to get more participation from people in
submitting patches). I know of no remotely exploitable security issue
that is now in current PHP version.
So I wonder what would you like PHP Group to improve? What would you
mean by facing reality - what in your opinion the reality is and what
would you have PHP group to do to satisfy you on facing reality account?
First of all PHP group is doing nothing. Neither do they improve PHP's
security nor do they stop well known PHP license abusers (because they
are friends).
Secondly security patches are done by Ilia and maybe the Zend stuff by
Dmitry. All the others are doing nothing in the sense of security.And do I need to remind you about a certain bug in the new super duper
Zend Memory manager that results in a far too small buffer being allocated?Do I need to post an exploit that uses this bug to exploit for example
the Soap HTTP client from ext/soap? This is a kind of remote exploit
against PHP. And god knows how many other places are vulnerable because
of the new "improved" Zend Memory Manager.And what about the heap underflow bug in ext/filter... Also not a remote
exploit?The fact that you do not know about any remote exploit against PHP is
quite irrelevant for reality.Stefan Esser
Rather then commenting on what other people should and should not do,
do something productive like fix bugs or help to extend the PHP test
suit.
This is pathetic. I thought most of you were adults, but I really
can't tell sometimes.Why can't this be discussed without everyone getting upset and
snapping at each other? The biggest problem with PHP right now is how
thick-headed and cocky some of the posters to this list are. Grow up,
and then maybe PHP will have a chance to grow up.It's only taken a couple months to realize how much time is wasted on
political crap on this list instead of bug-fixing.I wonder what do you mean by that - that PHP group should publish
press release "PHP is not secure, please do not use it anymore" or
what? I see PHP group is working quite well eliminating the
security
issues. As far as I know, last year there was 7 remotely
exploitable
issues in PHP (which is regrettable but that's the way of life
to have
bugs), and all of them are fixed, IIRC, and within acceptable
timeframe (the last can be debatable, but PHP being opesource
project
the only way to fix it is to get more participation from people in
submitting patches). I know of no remotely exploitable security
issue
that is now in current PHP version.
So I wonder what would you like PHP Group to improve? What would
you
mean by facing reality - what in your opinion the reality is and
what
would you have PHP group to do to satisfy you on facing reality
account?
First of all PHP group is doing nothing. Neither do they improve
PHP's
security nor do they stop well known PHP license abusers (because
they
are friends).
Secondly security patches are done by Ilia and maybe the Zend
stuff by
Dmitry. All the others are doing nothing in the sense of security.And do I need to remind you about a certain bug in the new super
duper
Zend Memory manager that results in a far too small buffer being
allocated?Do I need to post an exploit that uses this bug to exploit for
example
the Soap HTTP client from ext/soap? This is a kind of remote exploit
against PHP. And god knows how many other places are vulnerable
because
of the new "improved" Zend Memory Manager.And what about the heap underflow bug in ext/filter... Also not a
remote
exploit?The fact that you do not know about any remote exploit against PHP is
quite irrelevant for reality.Stefan Esser
--
--
Ilia Alshanetsky
That was my intent when I joined the list. I wanted to get a feel for
the community and the development process. This is the first
open-source project that I've considered contributing to, so it's all
new to me. I still plan to dive into it, but it's disheartening to see
some of these petty arguments. That is all...
Jordan
Rather then commenting on what other people should and should not do,
do something productive like fix bugs or help to extend the PHP test
suit.This is pathetic. I thought most of you were adults, but I really
can't tell sometimes.Why can't this be discussed without everyone getting upset and
snapping at each other? The biggest problem with PHP right now is how
thick-headed and cocky some of the posters to this list are. Grow up,
and then maybe PHP will have a chance to grow up.It's only taken a couple months to realize how much time is wasted on
political crap on this list instead of bug-fixing.I wonder what do you mean by that - that PHP group should publish
press release "PHP is not secure, please do not use it anymore" or
what? I see PHP group is working quite well eliminating the
security
issues. As far as I know, last year there was 7 remotely
exploitable
issues in PHP (which is regrettable but that's the way of life
to have
bugs), and all of them are fixed, IIRC, and within acceptable
timeframe (the last can be debatable, but PHP being opesource
project
the only way to fix it is to get more participation from people in
submitting patches). I know of no remotely exploitable security
issue
that is now in current PHP version.
So I wonder what would you like PHP Group to improve? What would
you
mean by facing reality - what in your opinion the reality is and
what
would you have PHP group to do to satisfy you on facing reality
account?
First of all PHP group is doing nothing. Neither do they improve
PHP's
security nor do they stop well known PHP license abusers (because
they
are friends).
Secondly security patches are done by Ilia and maybe the Zend
stuff by
Dmitry. All the others are doing nothing in the sense of security.And do I need to remind you about a certain bug in the new super
duper
Zend Memory manager that results in a far too small buffer being
allocated?Do I need to post an exploit that uses this bug to exploit for
example
the Soap HTTP client from ext/soap? This is a kind of remote exploit
against PHP. And god knows how many other places are vulnerable
because
of the new "improved" Zend Memory Manager.And what about the heap underflow bug in ext/filter... Also not a
remote
exploit?The fact that you do not know about any remote exploit against PHP is
quite irrelevant for reality.Stefan Esser
--
--
Ilia Alshanetsky
--
Jordan Moore - Creative Director
Sanctus Studios LLC
http://sanctusstudios.com
(360) 616-4818
First of all PHP group is doing nothing. Neither do they improve PHP's
security nor do they stop well known PHP license abusers (because they
are friends).
OK, that's just not true and it is obvious to anybody with access to the
commit logs (namely, everybody) - bugs are getting fixed and
improvements are getting done. You may argue they are not enough, but
you certainly can not claim that nothing at all is done. As for the
alleged license abuse, I am aware of your sensitivity in this regard,
however this has nothing to do with the subject of security, so it would
be very good if we stick to the subject.
And do I need to remind you about a certain bug in the new super duper
Zend Memory manager that results in a far too small buffer being allocated?
Actually yes, you do - I don't remember any unfixed bugs in Zend MM, so
if you know of an unfixed vulnerability there please do remind about it
- preferably through the security list, of course, so all the usual
people see it.
against PHP. And god knows how many other places are vulnerable because
of the new "improved" Zend Memory Manager.
If you have ideas on how to make it work better, you are more than
welcome to discuss it. By "discuss" I mean the thing regular people mean
- exchange ideas, evaluate their merits and hopefully reach decision
that is best for all, not that one participant calls others liars,
morons and useless marketing droids, dismisses everything they say as
propaganda and refuses to contribute anything. Any discussion in the
former sense is more than welcome, if you want to help - you can write
your proposals to me, for example. Last time I asked about this I got
response in lines of "why should I help?". However, the door is still
very much open.
And what about the heap underflow bug in ext/filter... Also not a remote
exploit?
Again, I was under impression the underflow bug was fixed. If you know
about another, unfixed one - please... you know.
The fact that you do not know about any remote exploit against PHP is
quite irrelevant for reality.
I can't avoid noticing that you forgot to answer my question. To remind,
my question was not "is my knowledge seems adequate to you". My question
was "what did you mean by recognizing the reality by the PHP group and
what do you propose to do". Could you please try again?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
This has just appeared:
Of many people who use PHP not many have strong programming
background and even fewer experience with security. The use PHP
because it makes it easy to solve problems, especially in a web
environment. When you consider this it is hardly surprising that many
people write bad and/or insecure code. While PHP does try to make
things better, and occasionally has bugs in the language core you
need to realize that PHP is a programming language. As such if you
really want to shoot yourself in the foot you can, just as you can do
with C/C++/Perl/Python/etc...
Ilia Alshanetsky
This has just appeared:
Of many people who use PHP not many have strong programming
background and even fewer experience with security. The use PHP
because it makes it easy to solve problems, especially in a web
environment. When you consider this it is hardly surprising that many
people write bad and/or insecure code. While PHP does try to make
things better, and occasionally has bugs in the language core you
need to realize that PHP is a programming language. As such if you
really want to shoot yourself in the foot you can, just as you can do
with C/C++/Perl/Python/etc...
I think that everyone would agree with that.
The discussion is how PHP can help them to discover problems in their
scripts. This is what led to Wietse Venema's suggestion about tainting
a few weeks ago. These may be things that members of this forum do not
feel that they need, but the ''quality'' of the majority of PHP
programmers is such that they would be of benefit.
To an extent it is an accolade to PHP that novice/... programmers can
use it do create applications, it just puts a greater burden on us to do
what we can to protect them from their own problems.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
The discussion is how PHP can help them to discover problems in their
scripts. This is what led to Wietse Venema's suggestion about tainting
a few weeks ago. These may be things that members of this forum do not
feel that they need, but the ''quality'' of the majority of PHP
programmers is such that they would be of benefit.To an extent it is an accolade to PHP that novice/... programmers can
use it do create applications, it just puts a greater burden on us
to do
what we can to protect them from their own problems.
The tools already exist, look at E_NOTICE for example. A good number
of PHP exploits are caused by register_globals + un-initialized vars.
If the developers of those apps tried to run their code with that
error reporting method enabled there would be far fewer security bugs
all around.
Ilia Alshanetsky
The discussion is how PHP can help them to discover problems in their
scripts. This is what led to Wietse Venema's suggestion about tainting
a few weeks ago. These may be things that members of this forum do not
feel that they need, but the ''quality'' of the majority of PHP
programmers is such that they would be of benefit.To an extent it is an accolade to PHP that novice/... programmers can
use it do create applications, it just puts a greater burden on us
to do
what we can to protect them from their own problems.The tools already exist, look at
E_NOTICEfor example. A good number
of PHP exploits are caused by register_globals + un-initialized vars.
If the developers of those apps tried to run their code with that
error reporting method enabled there would be far fewer security bugs
all around.
E_NOTICE flags up attempts to use an uninitialised variable, it is not
helpful if you assign to a typeo. This people do and can be hard to find,
especially if it is not in an often used code path.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
The discussion is how PHP can help them to discover problems in their
scripts. This is what led to Wietse Venema's suggestion about tainting
a few weeks ago. These may be things that members of this forum do not
feel that they need, but the ''quality'' of the majority of PHP
programmers is such that they would be of benefit.To an extent it is an accolade to PHP that novice/... programmers can
use it do create applications, it just puts a greater burden on us
to do
what we can to protect them from their own problems.The tools already exist, look at
E_NOTICEfor example. A good number
of PHP exploits are caused by register_globals + un-initialized vars.
If the developers of those apps tried to run their code with that
error reporting method enabled there would be far fewer security bugs
all around.
E_NOTICEflags up attempts to use an uninitialised variable, it is not
helpful if you assign to a typeo. This people do and can be hard to find,
especially if it is not in an often used code path.
That is why there is a concept called "testing" [1] and code coverage
[2].
[1]. http://phpunit.de/
[2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-Reports-with-PHPUnit-3.html
regards,
Derick
That is why there is a concept called "testing" [1] and code coverage
[2].[1]. http://phpunit.de/
[2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-Reports-with-PHPUnit-3.html
You are an experienced and careful programmer, that is why you understand the value
of doing this sort of thing. The trouble is that most PHP programers are
not experienced and/or careful ... that is why many PHP scripts have nasty bugs in
them.
As I said: we are looking at ways of helping the sort of person who would not
come near this mail list.
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
That is why there is a concept called "testing" [1] and code coverage
[2].[1]. http://phpunit.de/
[2]. http://sebastian-bergmann.de/archives/578-Code-Coverage-
Reports-with-PHPUnit-3.htmlYou are an experienced and careful programmer, that is why you
understand the value
of doing this sort of thing. The trouble is that most PHP
programers are
not experienced and/or careful ... that is why many PHP scripts
have nasty bugs in
them.As I said: we are looking at ways of helping the sort of person who
would not
come near this mail list.
Uhm those are PHP tools for PHP code, what do they have to do with
internals. Rather then whining about "if I only had tool XYZ" use
what's already widely available.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
This has just appeared:
http://www.theregister.co.uk/2007/01/11/php_apps_security/Of many people who use PHP not many have strong programming background
and even fewer experience with security. The use PHP because it makes it
easy to solve problems, especially in a web environment. When you
consider this it is hardly surprising that many people write bad and/or
insecure code. While PHP does try to make things better, and
occasionally has bugs in the language core you need to realize that PHP
is a programming language. As such if you really want to shoot yourself
in the foot you can, just as you can do with C/C++/Perl/Python/etc...
This is exactly what the article said.
"PHP shouldn't be blamed for its popularity, so I don't want readers to
get the wrong idea. Many lower level languages like C/C++ are even more
popular and give developers far more rope to hang themselves than PHP.
Therefore, there are other issues at play.
"Applications written in every language can, will, and have had a myriad
of security vulnerabilities over the years. It doesn't matter if it's C++,
Perl, ASP, Visual Basic, Python, or Ruby and Ruby on Rails. [...]
"I have no doubt that some PHP Group developers shake their head at the
very basic security mistakes that many new programmers make. The problems
are all over the web. They're user issues, so they probably don't concern
themselves with them. But they should. [...]
"I'm not saying the PHP Group is responsible, but they could help. As
architects of the language they should consider ways of hardening the
language and its defaults against some of the real basic mistakes so many
people are making."
The developers of the major PHP applications have to take some
responsibility as well. A sysadmin once told me "I'd disable
register_globals but the users complain that their applications break". No
doubt it's a common story.
Mark Krenz makes the same argument about safe mode. It can be difficult to
make things work in safe mode, open_basedir is much easier and probably
more secure.
Magic quotes are a nuisance for programmers at any level, definitely a
misfeature. The best way to avoid SQL injection is to use a query builder,
like we do in MediaWiki. PHP should have one built in. Prepared
statements, as in PDO, are a useful step in the right direction.
Shell escaping could be handled in a similar way. PHP does not even have a
working cross-platform shell escaping function. I would like to see
spawnlp-style functions in PHP -- you can't have shell injection when you
don't use the shell.
The situation with HTML injection (XSS) is much the same. The historic
lack of HTML construction functions means that programmers put the strings
together themselves, often not bothering to escape user input. An HTML
construction library which makes a clear distinction between HTML and text
input would go some way towards solving this, if it was promoted well
enough. Maybe DOM does this already, I'll tell you once I manage to
comprehend the documentation. It's certainly more verbose than the
equivalent in Perl.
Over and over, we see security vulnerabilities introduced due to the
manipulation of text-like protocols using string concatenation and
interpolation. The solution is to handle each and every one as a protocol,
not as a string.
-- Tim Starling