Good morning Tim! Glad to see you in such a great mood. :^P
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.
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.
> But... I'm hacker proof.
Yeah, you and Oracle. And I believe you both. Completely.
> > 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. 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. Sorry for coming across as saying that PHP is perfect,
that was certainly not the point. 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. Count the
number of PHP vulnerabilities - and compare that to the vulnerabilities
of PHP-based applications. That is what I am talking about.
> 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. 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. And no,
I'm not trying to say PHP is hacker-proof(TM). Only you and Oracle are
hacker-proof(TM).
> 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, but I can use plain old HTML to call remote
scripts, submit data, execute scripts locally, and even download
applets, crapplets and active-x, oh my! Yes, using HTML opens you up to
vulnerabilities found elsewhere (browsers, scripting languages, etc.) -
but that doesn't mean that HTML is perfect, does it? There's no need to
get wrapped around the axle on semantics here; very few sites nowadays
are written in plain, pure HTML... 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.
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?
Or do I need to go get them? Or am I the only person interested?
-- Mitch
---------------------------------------------------------------------------
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
----------------------------------------------------------------------------
