Den 2019-06-17 kl. 19:10, skrev Erik Lundin:
Background:
The latest version of PHP seems to handle fatal errors as exceptions
which results in stack traces being logged. Stack traces can
potentially contain sensitive information and should not be logged in
a production environment.
Test code:
<?php
function handle_password($a) {
does_not_exist();
}
handle_password('s3cretp4ssword');
PHP 5.4.16:
Jun 17 15:58:01 server php[29650]: PHP Fatal error: Call to undefined
function does_not_exist() in /var/www/html/index.php on line 3
PHP 7.4 (dev):
Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error:
Call to undefined function does_not_exist() in
/var/www/html/index.php:3#012Stack trace:#012#0
/var/www/html/index.php(5): handle_password('s3cretp4ssword')#012#1
{main}#012 thrown in /var/www/html/index.php on line 3
Suggested patch:
Add a configuration value to be able to prevent exceptions from
logging stack traces.
log_exception_trace = On/Off
It would be optimal to have this disabled as default as novice
administrators would perhaps not be aware that this information would
be logged. For debugging purposes it would be helpful to be able to
enable this but maybe the default value should be set conservatively
to minimize unnecessary problems?
I've added this configuration value in Zend/zend.c as the exception
message is compiled in Zend/zend_exceptions.c. Adding it to
main/main.c would change the scope from zend_compiler_globals to
php_core_globals and I guess that you wouldn't want to mix them?
Link to pull request: https://github.com/php/php-src/pull/4281
Regards, Erik Lundin
Hi,
In our environment these kind of errors goes to the Apache error log.
We have full control of the complete LAMP stack and it's only our
ISP who can access these. So little risk for leakage of sensitive info.
Now we have a large legacy code base that has been migrated from
PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
usage of these kind of stack traces in the production environment.
It helped us fixing the (hopefully) last issues. We also have a kind of
beta site, but we didn't got enough traffic on that one to trigger the
errors we got in production.
My 50c on this subject, well aware of that having "ownership" of the
LAMP stack is one prerequisite to not disclose sensitive info.
r//Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
