Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27508
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain adaniels.nl from 82.94.235.198 cause and error)
Message-ID: <45AE748D.5060803@adaniels.nl>
Date: Wed, 17 Jan 2007 20:10:05 +0100
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Alain Williams <addw@phcomp.co.uk>, Greg Beaver <cellog@php.net>,
        Stefan Esser <sesser@hardened-php.net>, Marcus Boerger <helly@php.net>,
        "internals@lists.php.net" <internals@lists.php.net>
References: <F1076B95-2D05-4690-AE84-21FC0552F17A@ch2o.info> <45A8FC49.7050909@hardened-php.net> <45A90809.3050008@lerdorf.com> <45A91002.8020607@hardened-php.net> <526994769.20070113181330@marcus-boerger.de> <Pine.LNX.4.64.0701141301180.32133@mail.zend.com> <45AA116F.7020109@hardened-php.net> <Pine.LNX.4.64.0701141436460.16363@mail.zend.com> <45AA961D.4090401@php.net> <45AD63A1.2040206@adaniels.nl> <20070117084600.GA19933@mint.phcomp.co.uk> <45AE62FE.2040805@zend.com>
In-Reply-To: <45AE62FE.2040805@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: info@adaniels.nl (Arnold Daniels)



Stanislav Malyshev schreef:
>>> fopen($file, 'r') and fopen($url, 'ru') and fopen('php://output', 
>>> 'ru').
>
> What about all other function using streams that do not have fopen 
> arguments? The whole idea of streams was for the things to work 
> transparently with all functions, if it were only about fopen there 
> were no reason to do streams...
>
With fsockopen() you expect to supply an url, so not restriction there.
file_put_contents ($file, FILE_ALLOW_URL);
file_get_contents ($file, FILE_ALLOW_URL | FILE_USE_INCLUDE_PATH);
The streams_* functions are an advanced feature. So developers working 
with that should just lookout them selfs.

Which functions am I forgetting?
We (at our hosting company) currently only see a lot of hacks appearing, 
where customers have implemented fopen or file_put_contents insecurely. 
This change would solve the bulk of the current stream hacks, not make 
streams 100% safe.

>>> To my opinion, using '*://' streams is an advanced feature. Developers
>>> who are using that, should be able to make sure no urls are opened.
>
> Again, all streams exist for that. And if we attempt to restrict local 
> developer (which IMO we should not, but _if_ we do) then we can't rely 
> on him at the same time.
It's a very small restriction. A developer only needs to add an 
'allow_url' flag to the function to make it work like it currently does.

Again, this solution wouldn't make everything 100% safe, but in 
real-world applications it would solve a lot of problems. And I believe 
that PHP is called unsafe by some, not because of the number of security 
issues, but because of the number hacks being performed on PHP websites. 
To give you an idea: We host about 2500 websites. An average of 1 
website per week is hacked (we hear of). About 50% is because of a 
posted file appearing within the document root, about 25% of those hacks 
are PHP related and 25% are other reasons.

Arnold