1

我有一个传递给Session对象的DB对象的实例，因为Session对象有几个方法可以利用DB对象来执行 SQL 语句，我计划将此DB对象存储在Session对象属性中。

通过测试发现，print_r暴露了存储在Session对象属性中的DB对象；输出中包含 db 用户/密码。

所以我的想法是将DB对象存储在一个私有静态成员中，以防止在Session对象print_r上调用此信息时泄露此信息。

这是可以接受的，还是只是对静态成员的错误使用？

什么是防止私有对象财产被泄露的推荐方法print_r？

这是代码示例。

前：

class Session 
{

    public __construct(DB $db)
    {
        $this->db = $db;
    }

}

后：

class Session
{

    private static $db;

    pubic __construct(DB $db)
    {
        self::$db = $db;
    }

}
4

3 回答 3

3

You can't stop print_r/var_dump/var_export from being able to read these, it has been reported several times to the php team but they consider it a feature (...) :

http://bugs.php.net/bug.php?id=39118&edit=2
http://bugs.php.net/bug.php?id=35822&edit=1

If you use a static member like in your exemple, please remember that every Session instance can access it/has the same; this can lead to some surprises later on.

Another idea is to wipe out the login/pass from the DB object once connected, this can help containing the issue.

于 2009-07-31T14:36:42.397 回答
0

Yes, this is bad

print_r() should only be used for debugging and not for displaying content to the user.

If the class contains secret information that schould not be visible to the tester, you have to sanitise (set the fields to empty string or something) the parts that are secret.

于 2009-07-31T14:33:54.587 回答
0

另一种方法是修改您使用 DB 对象的方式。如果会话方法需要使用 DB 对象，它们应该调用“global $db;” 在方法开始时确保敏感的 DB 登录信息实际上不是持久数据的 $_SESSION 对象的一部分，并且由调用页面定义适当的 $db 对象并且在其生命周期内不公开它脚本的执行，而不用担心它挂在 SESSION 对象中。

于 2009-07-31T14:49:03.813 回答