Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hardened-php.net from 81.169.146.190 cause and error)
Date: Sat, 13 Jan 2007 16:35:35 +0100 (MET)
Message-ID: <45A8FC49.7050909@hardened-php.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To:  info@ch2o.info
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <F1076B95-2D05-4690-AE84-21FC0552F17A@ch2o.info>
In-Reply-To: <F1076B95-2D05-4690-AE84-21FC0552F17A@ch2o.info>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: sesser@hardened-php.net (Stefan Esser)

Mathieu CARBONNEAUX schrieb:
>> http://us2.php.net/manual/en/ref.pdo.php#pdo.prepared-statements
>>     
> Sorry for my buz...
> This piece of manual say the same i've said...
>   
Yeah and it is wrong. The manual claims the following:

> The parameters to prepared statements don't need to be quoted; the
driver handles it for you. If your application
> exclusively uses prepared statements, you can be sure that no SQL
injection will occur. (However, if you're still
> building up other parts of the query based on untrusted input, you're
still at risk).

While it is true that the PHP script is not subject to SQL injection
when the application does not build parts of the query based on
untrusted userinput it is not true that you are not at risk.
Ever heard of stored procedures? And precisely of SQL injection in
stored procedures? Prepared statements can do nothing about SQL
Injection in Stored Procedures. And if you teach people that they only
should use prepared statements they will NEVER know that it is dangerous
to put userinput into the query. And aside from that they have never
learned how to do it correctly if there is ever a situation where they
have to do it.

> But i repeat, i thing a security (or a good dev practice portal) portal is a good freind of the manual and can be abel to level up the security of php dev app...
>   
There are enough secure programming examples by so called experts around
that are vulnerable to different kind of attacks. Do you really believe
a community portal by complete strangers can provide reliable security
documentation?
> And is bad for the php image...
>   
It is very good that bugs in PHP Applications are bad for PHP's image.
The majority of servers get hacked because of Remote URL Includes (and
not by XSS/SQL Injection). The existance of Remote URL Includes is fully
to blame on the PHP engine and is UNIQUE. After years the feature is
still not kicked out of PHP. In PHP 5.2.1 there will be a configuration
option that activates an (incomplete) blacklist. Everyone should know by
now that blacklists are BAD.
> On this portal i thing also be interesant log php alert in more friendly way...
>   
You mean like using marketing tricks to make security bugs look less
serious?


Stefan Esser
Hardened-PHP Project