----- Original Message -----
From: "Mitch Pirtle" <[EMAIL PROTECTED]>
To: "Tim Greer" <[EMAIL PROTECTED]>
Cc: "Chris Berry" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, July 02, 2003 10:54 AM
Subject: Re: Ten least secure programs
> Good morning Tim! Glad to see you in such a great mood. :^P
Is making a point deemed to be hostile in this world?
> On Wed, 2003-07-02 at 13:19, Tim Greer wrote:
> >
> > How is CGI an insecure program? It's an interface, and actually, I'm
not
> > aware of any security issues with this interface. If you mean that it
> > allows for a means for a user on a server with CGI access to do things,
> > that's true, but it shouldn't be an issue on a secured system and
therefore
> > means CGI isn't (the) a security issue (at hand).
>
> You know what, you're right. Based on that reasoning I suppose that CGI
> (e.g. apache with cgi-bin access) and fully-automatic assault rifles are
> good for everybody.
You're being ridiculous. On a secure system, CGI access poses no threat
whatsoever.
> Hey Mom, can I have a couple cases of hollow-points for Christmas?
> They're not dangerous on their own, and are actually quite safe when
> handled properly, so I suppose they're legal.
Why are you involved in this discussion if you actually lack the knowledge
about this subject?
> > But... I'm hacker proof.
>
> Yeah, you and Oracle. And I believe you both. Completely.
I'm glad you think so.... I didn't mean to hurt your feelings.
> > > Oh, IMNSHO, PHP isn't insecure, its the people using it.
> >
> > ...and the people coding it (PHP). Read the bugs and vulnerability
lists
> > regarding issues with PHP if you think it's only the people coding
insecure
> > programs that make PHP insecure (after all, that wouldn't qualify it as
inse
> > cure)
>
> Perhaps I was not clear enough.
No, I think you were.
> I do not think that PHP in itself is so
> insecure, it is just too easy to write code in PHP that can be
> manipulated.
Agreed, and that's the case for any langauge... though PHP itself is more
insecure than alternatives such as C/C++, Perl, Python, etc.
> Sorry for coming across as saying that PHP is perfect,
> that was certainly not the point.
Okay.
> What I'm trying to say is that from
> my experience there are many, many, many more poorly-written PHP
> applications than there are PHP security vulnerabilities.
Of course.
> Count the
> number of PHP vulnerabilities - and compare that to the vulnerabilities
> of PHP-based applications. That is what I am talking about.
I see, and yes, that's true of any language, evem if the language itself
doesn't have any security issues. I agree that poor coding by goof balls,
shouldn't reflect on the interface or langiage they (don't know how to)
use.... sort of like the CGI interface... and CGI scripts... you can't go
blaming a solid interface without issues, for the results of the foolish and
clueless coders that use (read, abuse) it.
> > We're not talking about coding insecure scripts as the security issues,
> > which is why I wonder why you mentioned CGI (I assume you mean CGI
> > scripts?)...
>
> Maybe you missed the first message.
No, but what did that have to do with CGI?
> PHP was listed as a 'forbidden
> technology', and I was pointing out that I believed it was poor
> programming giving PHP a bad rep, not necessarily PHP itself.
I see that now, but why the mention of CGI previously? Anyway, PHP itself
is buggy and insecure, since we were talking about that.
> And no,
> I'm not trying to say PHP is hacker-proof(TM).
Of course not. But the fact is, it has a lot of problems, and that is a
problem... and don't go trademarking that slang.
> Only you and Oracle are
> hacker-proof(TM).
Well, not Oracle, but I'm still running strong.
> > Anyway, HTML is not a programming language, and it's just HTML
> > tags being rendered and text, you can't write an insecure HTML page.
That
> > would be the user's browser that would be exploitable due to that,
unless
> > you think some silly Java, JavaScript or XSS thing means HTML is
insecure.
>
> Call it silly if you will,
Silly...
> but I can use plain old HTML to call remote
> scripts,
Not if I don't have JS or Java or something such as that enabled... which is
a browser issue.
> submit data,
How are you going to make me submit data that poses a security issue to
HTML? You mean use a meta-refresh tag, since I have Js disabled, and post
some data to a remote script somewhere? If so, how does that make HTML
insecure because a script I might be posting data to would be insecure?
> execute scripts locally,
Not with HTML you can't, and how does that make HTML insecure anyway? Oh,
you mean use HTML (the standard way most browsers interact with most things)
to exploit something else... well, what does that have to do with HTML? I
can use my browser's Address location bar to do that.
> and even download
> applets,
No, you can't. That's a browser issue and I'd have to have Java enabled.
> crapplets and active-x, oh my!
Active-what-now? Sorry, I don't use these browsers or options...
> Yes, using HTML opens you up to
> vulnerabilities found elsewhere
Well, not HTML...
> (browsers, scripting languages, etc.) -
Scripting languages are not HTML.... HTML is HTML.
> but that doesn't mean that HTML is perfect, does it?
Not if you assume it does more than it does. HTML is perfect and secure.
It's just text. If you put in an HTML tag to call an applet to exploit
someone's browser, that has no relevance to HTML being secure or not.
> There's no need to
> get wrapped around the axle on semantics here;
There is, if you continue to claim these silly things are a threat somehow.
> very few sites nowadays
> are written in plain, pure HTML...
That's irrelevant. You mentioned HTML being an issue, it's not.
> My point was that insecure PHP
> applications can be built in other scripting languages (complete with
> insecurities); and that just about every web-based environment has
> issues.
Well CGI doesn't have issues, not unless the web server itself is insecure
somehow... And, yes, any insecure function can be built into a script, but
that doesn't mean the langiage is insecure... PHP, on the other hand, is
(though not that bad, it is).
> You got me thinking though, I wonder how many pure-PHP vulnerabilities
> are discussed(tens?), as opposed to the me-too PHP-application
> vulnerabilities(hundreds?), versus other scripting languages (ASP, JSP,
> Perl, Python, etc.)? Anybody have these numbers?
Why bother wondering? There's millions of PHP coders out there, so there's
millions of insecure scripts out there. There's millions of ASP, JSP, Perl
and Python coders out there, so there's just as many insecure scripts
written in those other languages/interfaces as well. If you want to compare
how secure Perl is to PHP, feel free. You will find that it, for example,
doesn't suffer from the same issues PHP has a long history of.
> Or do I need to go get them? Or am I the only person interested?
You might be the only person interested. I don't need some stats to tell me
there's a lot of insecure scripts, and I keep up on this to know what PHP
has, as opposed to Perl, for example. PHP updates once every few months or
sooner sue to a security issue or bug, whereas Perl is updated every few
years for a new version with new functions added... that should tell you
something.
--
Regards,
Tim Greer [EMAIL PROTECTED]
Server administration, security, programming, consulting.
---------------------------------------------------------------------------
Evaluating SSL VPNs' Consider NEOTERIS, chosen as leader by top analysts!
The Gartner Group just put Neoteris in the top of its Magic Quadrant,
while InStat has confirmed Neoteris as the leader in marketshare.
Find out why, and see how you can get plug-n-play secure remote access in
about an hour, with no client, server changes, or ongoing maintenance.
Visit us at: http://www.neoteris.com/promos/sf-6-9.htm
----------------------------------------------------------------------------
