Security Perceptions: Re: [PHP-NOTES] note 8760 added tofopen

This hit the errata Wednesday. (And I also posted this message to PHPdoc on thursday) In light of the recent bugtraq fun and games, I figured I'd relay this into active discussion. I'm sure there's more than a few "error conditions" which report back more data than expected.... Ideas: 1. Point out in the security section that the best way of dealing with errors is to *hide them completely* from end users. 2. Keep this possible issue in mind when coding errors for PHP internals. 3. Start documenting what errors are thrown, and when. (This is a biggie, but it's an occasional errata request) -Bop kessler@kessler-design.com wrote: > Possible security-problem with fopen() if error-reporting is not suppressed. > Imagine you use 2 scripts on same or different hosts, but only first one is visible for the > user. Within the first script, you construct an URL with some (maybe not public) parameters to call > the second script, parse it's output and return something to t he > user, still from the first script. > #we are in script1.php and we construct the URL, then we try to open it > > $filename="http://domain.com/script2.php?someparam=1&somemore=2"; > $fh = fopen($filename, "r"); > if ($fh) { > # ... > } > > If the host (of second script) is not reachable, we wait a while and then get (with > 'normal' error-reporting) the following text with the users browser-window. > Warning: > fopen("http://domain.com/script2.php?someparam=1&somemore=2","r") > - Unknown error in domain.com\script1.phtml on line xxx > The error-report shows the whole (not public) filename of the second script including all (not > public) params instead of a simple connection timeout-message. > Make sure that you set error_reporting if you have to use such constructions. > http://www.php.net/manual/function.fopen.php -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary.