3

使用extract($_POST)不安全？如果是，那么我该怎么办？

4

5 回答 5

6

是的。它与 register_globals 是一样的。这意味着如果有人注入一个名为“my_name”的值，则变量“my_name”将存在。如果它存在，如果您在某个地方使用该变量，它可能会在您的脚本中带来一些垃圾或安全问题$my_name

于 2012-08-10T18:38:36.910 回答
5

从 php 文档：

不要对不受信任的数据使用 extract()，例如用户输入（即 $_GET、$_FILES 等）。如果这样做，例如，如果您想临时运行依赖于 register_globals 的旧代码，请确保使用不可覆盖的 extract_type 值之一，例如 EXTR_SKIP 并注意您应该按照 variables_order 中定义的相同顺序进行提取php.ini。

推荐的做法是$_POST[<varname>]直接使用，这样您网站的用户就不能设置应该是“安全”的变量

于 2012-08-10T18:39:29.460 回答
1

是的，它是不安全的。任何人都可以覆盖您的局部变量（例如$passwordor $access_level）。

我建议像这样声明和分配你自己的局部变量：

$var1 = isset($_POST['field_1'])?$_POST['field_1']:null;
$var2 = isset($_POST['field_2'])?$_POST['field_2']:null;
$var3 = isset($_POST['field_3'])?$_POST['field_3']:null;
于 2012-08-10T18:40:31.120 回答
1

extract($_POST)正如其他人所说，使用是不安全的。您询问了如何extract($_POST)确保安全，特别是避免不断引用$_POST数组。

字面答案

您询问了如何extract($_POST)安全使用。在定义任何局部变量之前或使用和 前缀之前，将其用作脚本的第一行是比较安全的。然而，在这两种情况下，您都在进行一场冒险的赌博，您永远不会在该变量范围内的任何地方通过拼写错误意外引入安全漏洞。全球范围非常难以验证。因为所有的程序员都会打错字，并且不便之处很小，所以大多数程序员强烈建议不要使用不受信任的内容，无论范围、前缀等如何。EXTR_PREFIX_ALLextract()

正确答案

$_POSTed 数据不可信且不安全。你永远不知道它可能包含什么——或者它是否会被设置。$_POST在将其分配给局部变量之前，将其视为必须“清理”的“污染”数据是很有用的。因此，您应该能够$_POST通过在将输入分配给局部变量时验证输入来最小化“”的输入。PHP 5.2 及更高版本使用带有验证过滤器的filter_input()和函数使这更容易。filter_var()

顺便说一句，您应该始终验证您的输入并清理您的输出。如果您改为清理输入，您可能会遇到在不同上下文中显示它们的问题（即，非 HTML 记录器，打印到终端）。如果你不清理你的输出，你就会遇到 XSS、SQL 注入等。

这种思维方式鼓励的经验法则是将所有从您无法控制的系统进入您的系统的数据视为“受污染的”、不可信的 - 您可能无法控制运行 Web 浏览器的系统，除非为 LAN 开发。此外，“纵深防御”鼓励将甚至受信任的系统视为可妥协的（它确实发生了），这使得这成为程序员最普遍的最佳实践。

于 2015-01-23T13:33:51.200 回答
0

最好简单地从中读取值$_POST并对其进行处理，而不是仅仅将它们作为变量公开并冒着覆盖你的一些风险......

于 2012-08-10T18:40:05.247 回答