Req #73536 [Nab]: var_dump ignore private permitions in class

From: Date: Thu, 24 Nov 2016 10:44:53 +0000
Subject: Req #73536 [Nab]: var_dump ignore private permitions in class
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-205601@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73536&edit=1 ID: 73536 Updated by: yohgaki@php.net Reported by: peter dot mlich at volny dot cz Summary: var_dump ignore private permitions in class Status: Not a bug Type: Feature/Change Request Package: Unknown/Other Function PHP Version: 5.6.28 Block user comment: N Private report: N New Comment: Just curious. If you want to steal "private" property info, why don't you use debug_zval_dump()? $ php -r 'class foo { private $p = "abc"; } $o = new foo; debug_zval_dump($o);' object(foo)#1 (1) refcount(2){ ["p":"foo":private]=> string(3) "abc" refcount(2) } I guess you would like to hide sensitive information in script/object variable from malicious "modules"/"extensions", but it's impossible for many languages/platforms. Java does not allow to dump objects like PHP. Not sure how well other scripting languages hide private property (and app installation path). Are there scripting languages hide private property well and/or hide file path information? (I'm curious about path, too. You can get file path by __FILE__ constant to know app installation path) Mitigation: var_dump()/debug_zval_dump()/get_included_files()/etc are debugging functions. Disable them by disable_functions INI. Or applications can tokenize module/extension PHP code and check unwanted functions. This is very fragile security measure because of nature of blacklist security, though. disable_functions is INI_SYSTEM main/main.c:562: PHP_INI_ENTRY("disable_functions", "", PHP_INI_SYSTEM, NULL) I guess most secure apps are using environment variables for security sensitive information, so getenv() should be restricted in this case. However, getenv() may be used for good reasons. We may consider change it to INI_PERDIR, perhaps? It may not be feasible. I don't check the code. "Securing PHP application module/extension" is interesting topic, but we don't provide it now. Suggestions are welcome. e.g. Framework that is relatively secure PHP script module/extension, hides application's sensitive information. Previous Comments: ------------------------------------------------------------------------ [2016-11-24 07:33:13] peter dot mlich at volny dot cz example: $path = '...'; $str = file_get_content($path); $CFG = parseXYZ($str); $my_class->setCfg($CFG); unset($path); unset($CFG); var_dump($path); You not know $path, if you not read this file. You can use file_get_content. But, i can use fileReader.php, read from directory blocked by .htaccess for only read for only this file. I can counting reading files in private variable. Readed cfg or not. You cannot use double times to read one file. ------------------------------------------------------------------------ [2016-11-23 08:12:44] rasmus@php.net A simple call to get_included_files() or a shell out to a grep will trivially get the file path. ------------------------------------------------------------------------ [2016-11-23 06:51:19] peter dot mlich at volny dot cz Must know file path. But, if i open file do $tmp and rewrite to clas, unset($tmp), unset($CFG), hacker no have information. ------------------------------------------------------------------------ [2016-11-20 15:45:38] rasmus@php.net If a hacker has access to write arbitrary PHP on a site he can simply open up the file containing the private properties and look at them. The access level of a property is not a security feature. ------------------------------------------------------------------------ [2016-11-20 08:02:17] peter dot mlich at volny dot cz If it not bug, then lucky day for hackers. If i hide db name, psw dto class, hacker can easy show it only with php command :) I think, this is very stupid bug. I now need find new methode to hide password. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73536 -- Edit this bug report at https://bugs.php.net/bug.php?id=73536&edit=1

« previous php.bugs (#205601) next »