【问题标题】:How to demonstrate an exploit of extract($_POST)?如何演示提取($_POST)的利用?
【发布时间】:2011-04-19 18:18:52
【问题描述】:

不是 PHP 开发人员,但我正在评估 PHP5 应用程序的安全性。

作者在函数之外的某些地方依赖extract($_POST)extract($_GET)

我的建议是调用extract($_POST, EXTR_PREFIX_ALL, 'form') 并相应地更改代码,但他的立场是任何变量都会在后续包含中重新定义。

我可以通过在帖子值中提供例如_ENV=something 来轻松更改超全局变量,但超全局变量是数组,我将它们转换为字符串,我不确定它是否会产生不良影响。

我可以看看isset() 的几个用法,然后从那里倒退。但我想有些攻击不需要知道或占卜来源。

是否有一些有趣的变量需要设置/更改,可能在 PHP 的内部?

谢谢

【问题讨论】:

  • 唯一想到的就是以这种方式覆盖超全局(即在$_POST 中定义一个名为_SERVER 的数组并将其提取到全局空间中)。那可能吗?它会覆盖$_SERVER 吗?可能不会(我希望)。我得试试看。
  • 是的,它至少适用于 _ENV。提供 EXTR_SKIP 可以解决这个问题。
  • (建议) 使用 Suhosin 可防止覆盖超全局变量并有助于缓解可能的攻击媒介。

标签: php security


【解决方案1】:

为了评估“可能”,试试这个:

文件:htdocs/mix/extraction.php

<?php
extract($_GET);
var_dump($_SERVER);//after extract
?>

然后这样称呼它:

http://localhost/mix/extraction.php?_SERVER=test

在我的 Xampp 上提取后,输出看起来像这样:

字符串(4)“测试”

如果有人知道你的变量命名并且你在 $_POST 或 $_GET 全局变量上使用了 extract,那么你有一个严重的问题。 通过一些时间和工作,可以通过尝试和错误找出一些命名。

在不知道您的来源的情况下,入侵者可能会尝试劫持任何全局变量,例如 $_SESSION(但这里只有在您执行 session_start(); 在提取($_GET)、$_COOKIE 或 $_SERVER 和甚至像这样为它们设置特定的值:

//localhost/mix/extraction.php?_SERVER[HTTP_USER_AGENT]=Iphone

如果你像这样使用提取物:

提取($var,EXTR_SKIP);

extract($var,EXTR_PREFIX_SAME,'prefix');

extract($var,EXTR_PREFIX_ALL,'prefix');

那么你就绝对安全了。

【讨论】:

  • 起初我以为你的回答只是重申我们已经说过的话。然后我尝试像这样设置特定的数组项,哦,我的上帝 :)
【解决方案2】:

数据库连接的通用名称是 $db,但这只会炸毁系统,您可以覆盖 $_SESSION 变量。

session_start();

$_SESSION['test'] ='test';
var_dump($_SESSION);
$vars = array("_SESSION" => 'awww');
extract($vars);
var_dump($_SESSION);

输出

array(1) {
  ["test"]=>
  string(4) "test"
}
string(4) "awww"

覆盖变量$idUser 或其他有趣的东西,想要搞乱迭代? 通过array('i' =&gt; 5)提取,根据范围可以有各种乐趣。

编辑:

我刚想到另一个,如果表单正在处理文件上传,为什么不尝试覆盖名为$file$fileName$fileExtention 的变量,看看你是否可以让它读取超出你权限级别的文件。

【讨论】:

  • 像其他超全局变量一样,_SESSION 是一个数组。我可以将其更改为字符串,但从那时起使用 _SESSION 只会导致错误。现在我正在查看具体的变量,谢谢。
【解决方案3】:

我不知道任何普遍的可利用性。

无论如何,这绝对是非常糟糕的做法。

脚本作者的意思是,脚本的安全性依赖于他不会忘记后续包含的任何内容,这太可怕了。

有关反对全局提取()的强有力的一般论据,请参阅What is so wrong with extract()?

【讨论】:

  • 不幸的是,我没有权力只说“这很糟糕”,否则我不会问:-(
  • @MarcoMariani,如果你确实有权力说“这很糟糕”,你应该问的越多,知道
猜你喜欢
  • 2012-01-07
  • 1970-01-01
  • 1970-01-01
  • 2011-11-07
  • 2021-05-02
  • 1970-01-01
  • 2023-03-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多