4

Given this example:

class Database
{
    private $host,
            $database, 
            $username, 
            $password,
            $type;

    public $active_connection;

    //Some methods
}


class Page
{
    private $db;


    public function __construct($id)
    {
        // Some code

        $this->db = new Database($id);
    }

    //Some Methods
}


$page = new Page(0);

var_dump($page);

This will output the private variables of Database Object, even though they are marked as private (and so, as I understand it, unusable by the outside world).

My questions are:

  1. Is this a security risk?
  2. Is there a way to effectively hide those variables marked as private?

thanks in advance

EDIT: In this project, the admin section will provide the ability to create custom PHP scripts to incorporate in the site, as sections. Since this is being developed to a third party entity, my concern is that, for some reason, the costumer inadvertently dumps the $page object (which is, in our code, the main modifiable object) in order to "explore" it.

Tivie
  • 18,864
  • 5
  • 58
  • 77
  • 1
    Attribute visibility is no security feature. And `var_dump` just happens to be a debug function. – mario Oct 24 '11 at 23:24

7 Answers7

6

Encapsulation is an architectural mechanism, not a security measure, and can't be used as such.

How exactly would an attacker exploit this security risk? It's only accessible from inside the source code, so he can as well read the source code for your protected class, or any other source code in the project.

Besides, even in C++ you could get access to private members by preparing a pointer with the right offset into the object.

Leonid Shevtsov
  • 14,024
  • 9
  • 51
  • 82
  • In this project, the admin section will provide the ability to create custom PHP scripts to incorporate in the site, as sections. Since this is being developed to a third party entity, my concern is that, for some reason, the costumer inadvertently dumps the $page object (which is, in our code, the main modifiable object) in order to "explore" it. – Tivie Oct 25 '11 at 11:21
4

New Magic method __debugInfo() was introduced in PHP 5.6 that will allow you to modify the default behaviour of var_dump() when dumping your objects.

Have a look at the documentation.

Example:

<?php
class C {
    private $prop;

    public function __construct($val) {
        $this->prop = $val;
    }

    public function __debugInfo() {
        return [
            'propSquared' => $this->prop ** 2,
        ];
    }
}

var_dump(new C(42));
?>

Returns:

object(C)#1 (1) {
  ["propSquared"]=>
  int(1764)
}

Although this question is 3 years old, I'm sure someone will find this useful in the future.

Dušan Brejka
  • 802
  • 9
  • 18
4

var_dump() shows them, because it's special. You can also dig around in private/protected properties using the Reflection API.

echo $object->_somePrivateVar;

On the other hand, will not expose _somePrivateVar.

1) Is it a security issue? Not at all. If you don't trust the code you're executing, you're pretty much boned.

2) Hide them from what? They're already hidden according to the data-visibility rules of the class system. But the language is dynamic, and provides some other ways to peek inside. As Leonid just said in his answer, this in an architectural mechanism, not a security feature.

timdev
  • 61,857
  • 6
  • 82
  • 92
  • Ad 2) To hide them for example from exceptions/errors reporting like [this](http://stackoverflow.com/questions/6455018/why-does-pdo-print-my-password-when-the-connection-fails). Then you can use magic method `__debugInfo()` to hide your vars from var dumping/exporting/reporting. – Krzysztof Przygoda Mar 27 '17 at 16:24
2

var_dump is intended for the developer to track and debug the code. From the documentation:

In PHP 5 all public, private and protected properties of objects will be returned in the output.

Tom
  • 4,910
  • 5
  • 33
  • 48
1

I know this is an old question, but I'd like to point out a (fairly) effective means of masking a variable;

You can create a function inside of the class which houses static variables; If you have a variable you really feel needs to be hidden from the system itself, save it into the functions' static variable. As long as that function is private to the class, it becomes very difficult to peek inside. This is O.K. if for some reason your server is dumping values out to userland and you can't control it.

But like TimDev said: if you don't trust the code you're executing, it's a sign that you have some larger security issues. Even if you have a plugin-based project with potential malicious pluin authors, you're simply not going to be able to protect yourself in that environment. It would be up to the administrator who installs those plugins to ensure security.

Kver
  • 767
  • 5
  • 19
1

This is documented behaviour for var_dump (as well as with print_r and var_export). This is intended as a way to gain visibility into your running code; for example, while debugging it you would want to know value of the private variables.

You can trap the output using output control functions, or use var_export if you need to use the private variable's contents in another class. This would be an unusual situation: you would most likely be using a public variable in that case anyway. If you were developing some kind of test suite that needed to verify the contents of private variables, this would be your answer.

Mike
  • 1,647
  • 15
  • 14
0

Check out __debugInfo() magic method in PHP manual how to hide sensitive data from stack traces (added in PHP 5.6.0). Here is an example:

class PDO_Database
{
    private $db_user = 'my_user';
    private $db_password = 'my_password';

    /**
     * The purpose of this method is to hide sensitive data from stack traces.
     *
     * @return array
     */
    public function __debugInfo()
    {
        $properties = get_object_vars($this);

        $hidden = [
            'db_user' => '***',
            'db_password' => '***',
        ];

        return $hidden + $properties;
    }
}
Krzysztof Przygoda
  • 1,217
  • 1
  • 17
  • 24