First of all, looking over this, this is all alreadly covered by
the (possibly anemic) security section..which could
definitely use more examples, explanations, and exploit examples
(hint hint).
On Wednesday, July 4, 2001, at 10:05 AM, sterling hughes wrote:
On 03 Jul 2001 19:13:20 -0700, Rasmus Lerdorf wrote:
On 4 Jul 2001, sterling hughes wrote:
Ah well, I'm guessing most people have already seen this, still, I
couldn't help passing it along... There are some good points
(nothing
we haven't discussed before) and some pretty bad points as well.
A lot of these are rather silly and are actually present in other
scripting languages when they are used in a web environment.
Most of it
boils down to the fact that you cannot trust user data.
Bingo. A perl script which does not check input is as bad as a
javascript is as bad as PHP...
I found the article interesting because it addressed the sheer
amount of insecure code (and coding practices) out there. PHP is
a powerful language, much more so than javascript or DHTML, and
yet, that is often what it is compared to. OTOH, it has as much
power as a CGI, which webmasters/sysadmins know to handle
delicately, _because_ of root exploits. Server admins need a
heads up, methinks, and a warning that PHP is a language that
*can* do nasty things.
The fact that
user data is easier to get at in PHP doesn't really change the model.
Making it harder to get the user data doesn't help if this
data is still
not checked and used incorrectly once you do get it.
But, I do think it would be worthwhile to go through these and add a
section to the documentation highlighting the pitfalls and
explaining how
to avoid them.
cough See above. :-)
I think the main point I agree with is that since many beginning users
use PHP to implement there websites, PHP should be more secure than
other languages, and have less places where the user can mess up.
PHP owes it's success to being easier to use. The more we try to
lock it down, for security reasons, the more it becomes harder
to use. (I think register globals off is silly, myself... a
determined cracker can't figure out how to forge a get instead
of a post, or vice versa?). Sure, we can switch to forced
typing, fixed buffers, but what's the point? To become C? If
that was what folks wanted, they'd learn C in the first place.
And it won't slow down crackers. The exact same article could
have been written with minor changes (a paragraph or less) to
show forging get/post/cookies, because PHP coders are often
*sloppy* about their vars.
It's security through obscurity (guess which of the whopping
four (GPCS) places I'm using?) it's an illusion, not a
solution.
Beginning users grab bad cgi's, horrid javascript, etc. Newbies
are newbies. The problem is not that PHP does too much, the
problem is that it's not being recognized for the level of power
it has, and treated accordingly.
I think the security section to the documentation is a superb start,
add away!
however, I also think that PHP5.0 since we are breaking
language compat,
perhaps we should turn off register_globals by default?
Uhm... I think you'll break pretty much *everything* out there.
Horrifically.
I don't personally know a single PHP developer who want to type
an addtional 14+ chars everytime they pick out a variable, and I
haven't seen much code where people actually do this. Have you
taken at look at ours? The code driving our php.net website? :-)
Suggestions/Ideas to mock or approve/improve upon.
1. Modify the secured var stack names, so calling something
like $PHPG[a] Is equivalent to HTTP_GET_VARS[$a] ( PHPP |
PHPS | PHPC | PHPF). Less typing of chars is good. Carpal tunnel
injuries bad.
2. Warn users. Put warnings in everytime something is called
from globals, without being initialized off of a clean stack.
(Which is dirty anyways, but some folks think it'll help slow
down hackers by 3/4ths or, on a 10 hits per sec website, by
less than a second).
3. beef up the security section
4. Start talking about PHP as if it was as powerful as it really
is... sure, it can make dynamic websites, but it can also
reformat your hard drives.
5. Eat our own dogfood (An americanmism). Make all our code
clean first, and learn from that.
-Bop
--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those
of myself,
my employers, or any of the other little voices in my head.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
