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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
