1

我知道不应该使用寄存器全局变量，但不太明白为什么？

例如：这是我经常发现的代码，用于演示在example.com?authorized=1向脚本传递类似内容时使用寄存器全局变量的安全风险：

if (authenticated_user()) 
{ 
$authorized = true; 
} 

if ($authorized) 
{ 
include '/highly/sensitive/data.php'; 
}

我的问题是，如果用户必须传入authorized=1url，他应该知道我在脚本中使用的变量名，对吗？这怎么可能？

parse_str()同样，类似于注册全局变量的功能也不是安全风险吗？

4

4 回答 4

5
  1. 攻击者可能通过另一个安全漏洞或隐私泄露访问您的源代码。
  2. 攻击者可以猜测。构建一个机器人来枚举所有可能的变量名称并在数千个 php 站点上尝试它们是非常简单的。( ?authorized=1, ?login=1,?access=1等)

编辑

作为回应parse_str，这取决于用例到底是什么，但总的来说可能。如果parse_str通过任何用户提供的内容，那么是的，绝对不安全。

可能有一些合法的用例，其中提供的输入不是用户提供的，但总的来说我会远离它。

我也会说同样的话extract：http ://ca1.php.net/manual/en/function.extract.php

于 2013-01-02T05:37:52.303 回答
2

想想为什么你曾经authorized命名你的变量？制作是描述性的吗？黑客在 url 中使用字典单词register_globals，如果打开，则设置此类描述性变量

于 2013-01-02T05:39:01.967 回答
1

虽然黑客确实需要知道变量名，但在许多情况下，这些变量名很容易猜到，并且尝试暴力破解是一项微不足道的任务。

当您使用开源软件、插件或复制/粘贴流行的代码片段时，这一点变得更加真实。

于 2013-01-02T05:39:55.917 回答
1

首先register_globals是安全风险。

  • 它是在 PHP 级别打开的，因此您不能说只引用一个脚本打开它是安全的。
  • 程序员（可能是任何程序员，而不仅仅是您）将不知道如何$authorized设置，并且可能会无意中在代码中留下安全漏洞。
  • register_globals注册的变量superglobals意味着它们可以在 PHP 脚本中的任何范围内使用。

接下来我们来看parse_str。此函数仅将变量解析到代码的当前范围（参考）。任何程序员都可以查看当前范围并确定他们是否以及如何保护它。它仍然不是很安全，但不像register_globals.

于 2013-01-02T05:47:19.790 回答