Ted Phillips <pega...@vaultwiki.org> schrieb am Do., 7. Juli 2016, 21:37:
> Right, so I think the only issue would be when we hide the path to {main}
> and anything relative to that. The trade-off would be that the developer
> will need to be familiar with his/her own directory structure. After
> thinking about it some more, there is the possibility that there are
> multiple scripts with the same name at multiple levels (e.g. /www/a.php and
> /www/deeper/a.php) that both might be accessed directly. Therefore, I think
> we should use the document root (I can't imagine a case where PHP would not
> know it), in case it is different from PHP_SELF (not familiar with how they
> work together). I don't know of another way that would be useful for
> max_input_vars errors and similar.
>
> Comparatively, if we hide anything in the include path, and replace it
> with [inc], the developer will know it's in one of the include paths.
> Any other custom paths and replacements would usually be developer
> specified like fpd_hide_path('/home/acct/git/lib', '[git]'), so the
> developer would be able to figure it out.
>
> If the error is written to a log file, I'm not sure that there is a reason
> to filter paths in the log file, but maybe you want to provide an option
> for it.My
Why do you want to hide paths in log files?
suggestion is mainly for errors that are sent to the browser or that are
> likely to be sent to the browser after being caught (debug_backtrace).
>
> Here's a case showing what happens to the document root:
>
> Before:
> -------
> Fatal Error: Uncaught Error: Call to undefined method
> Fake_Class::nonexistent_method() in /home/acct/www/script.php:2
> Stack trace: #0 {main} thrown in /home/acct/www/deep/script.php on line 2
>
> After:
> ------
> Fatal Error: Uncaught Error: Call to undefined method
> Fake_Class::nonexistent_method() in /[path]/script.php:2
> Stack trace: #0 {main} thrown in /[path]/deep/script.php on line 2
>
> If the first error is sent to the browser, a third party learns the site's
> acct name on the web server.
>
FPD isn't a vulnerability by itself. It can just be used as help if other
vulnerabilities appear.
If the second error is sent to the browser, the third party doesn't really
> learn anything.
The third party learns there's a fake class with some method that is
doesn't have.
If there's a stack trace, there may be passwords or other sensitive
information in it.
Short story short: You shouldn't ever display errors from PHP in
production. Thus such a change is unneccessary.
When the traces get longer, and we include files above the root for some
> reason, maybe I would say just use /[path]/../sidepath if there's not a
> specific replacement for it. This would only be an problem if users are
> including files from other people's accounts
Seems like you're on shared hosting with everything being in the webroot
automatically. That's often not the case and many apps will explixitly
store their code outside of the document root so they don't disclose their
source in case of an server configuration error.
or are using really strange paths; even so, the output wouldn't disclose
> any more information than the current implementation.
>
> Thanks,
> Ted
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
