Sascha Schumann
05/04/03, 00:20
Hello,
let me add a number of points from my perspective as member
of the PHP Group.
> What if the code looked something like this?
>
> <?php
> $num = $_REQUEST['num'];
> str_repeat("A", $num);
> ?>
This is a violation of the trust model in which the
application absolutely must not trust incoming data from the
client. Incoming data must be validated and proper bounds
checking needs to be applied at the application level.
It is not a specific issue of PHP; it is an issue all
applications have to address which exist and operate in a
dangerous and hostile world like the Internet.
We all know, of course, that checks are often incomplete or
even don't exist at all. That is why PHP contains a built-in
memory manager which enforces strict limits on resource
consumption. This significantly reduces the impact of
incomplete input validation.
> How many otherwise innocent functions in PHP can have unexpected
> results if an attacker can control one of the parameters?
An attacker should not directly control parameters in a
correctly written application. There should always be a
validation layer between user input and application logic.
> As I said, I'm not familiar with PHP. I welcome any clarifications or
> corrections. But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.
The PHP Group has initiated a semi-automated code coverage
test system which verifies the correct operation of PHP
functions when presented with uncommon input data. The
system has been extremely effective at uncovering issues and
aiding developers in addressing these.
The results of this measure will be available to our users as
part of the next release, PHP 4.3.2.
- Sascha
let me add a number of points from my perspective as member
of the PHP Group.
> What if the code looked something like this?
>
> <?php
> $num = $_REQUEST['num'];
> str_repeat("A", $num);
> ?>
This is a violation of the trust model in which the
application absolutely must not trust incoming data from the
client. Incoming data must be validated and proper bounds
checking needs to be applied at the application level.
It is not a specific issue of PHP; it is an issue all
applications have to address which exist and operate in a
dangerous and hostile world like the Internet.
We all know, of course, that checks are often incomplete or
even don't exist at all. That is why PHP contains a built-in
memory manager which enforces strict limits on resource
consumption. This significantly reduces the impact of
incomplete input validation.
> How many otherwise innocent functions in PHP can have unexpected
> results if an attacker can control one of the parameters?
An attacker should not directly control parameters in a
correctly written application. There should always be a
validation layer between user input and application logic.
> As I said, I'm not familiar with PHP. I welcome any clarifications or
> corrections. But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.
The PHP Group has initiated a semi-automated code coverage
test system which verifies the correct operation of PHP
functions when presented with uncommon input data. The
system has been extremely effective at uncovering issues and
aiding developers in addressing these.
The results of this measure will be available to our users as
part of the next release, PHP 4.3.2.
- Sascha