0

我正在构建一个 PHP 框架，其中我有一个解析 url 以及$_GET,$_POST和$_FILEsuperglobals 的请求对象。

我想鼓励安全的网络习惯，所以我保护数据免受 SQL 注入等。

为了确保该框架的用户通过请求对象访问安全、干净的数据，我计划unset($_GET, $_POST, $_REQUEST);在解析这些变量后使用。

我将在方法注释中记录这一点，并在框架文档中解释这种情况正在发生。

我的问题是：这会是可取的行为吗？有哪些我没有预见到的潜在陷阱？

4

5 回答 5

5

我知道这已经被回答了，但这是我的 0.02 美元。

我不会取消设置或清除输入数组。但是，我所做的是用一个对象替换它们。因此，我没有使用原始数组，而是将其替换为实现ArrayAccessand的对象Iterator。这样，绝大多数使用本机数组的代码仍然可以很好地处理对象。

理由是至少您可以通过测试验证代码路径是否正确运行。您可以用模拟对象替换这些对象以在测试期间引发异常，以便您可以检测到对这些数组的不正确访问（如果您确定这是“不好的做法”）。因此，它可以让您在生产期间运行而不会施加不必要的限制，还可以让您在测试期间打开它以验证最佳实践。

虽然我同意@JW 关于转义的观点，但您应该过滤输入。过滤进来，逃出去。任何时候数据进入您的程序（通过用户输入或来自数据库），将其过滤为预期值。任何时候数据流出（到数据库或用户），您都需要为该介质正确地转义它。因此，使用可以轻松过滤提交数据的请求对象可能非常有价值。

使用流畅界面的示例（您可能想要也可能不想要）：

$id = $request->get('some_id')->filter('int', array('min' => 1));

这不包括补偿不同平台和配置的好处（例如，是否magic_quotes_gcp启用等）......

无论如何，这只是我的意见...

于 2011-01-18T03:50:31.923 回答
3

我不确定阻止访问 $_GET 或 $_POST 数组的意义何在。他们没有什么有害的。如果您正在创建一个框架来防止 SQL 注入或跨站点脚本，您应该在创建 SQL 查询或 HTML 文档时转义数据。

一开始就转义 GET/POST 数据为时过早；您不知道数据将如何被使用，因此您无法对其进行转义或正确编码。

话虽如此，您仍然可能有一些正当理由希望人们通过您的代码访问 GET/POST 数据。在那种情况下，我仍然不会取消设置它们。您最终可能会合并依赖它们的第三方代码。相反，只是鼓励您的用户避免使用它们（就像他们通常应该避免使用全局变量一样）。

于 2011-01-18T03:05:50.547 回答
1

我可能会公开一种方法（可能是隐藏的或超级反直觉的；））来获取原始数据，以防您的清理程序以某种不可预见的方式损坏数据。保护用户是一回事，但是完全锁定他们以最原始的方式检索数据的能力可能会导致挫败感，结果是那些不使用您的框架的人:)

于 2011-01-18T02:56:50.157 回答
0

请记住，这会增加您的维护成本...如果使用 PHP 中的超级全局变量添加、删除或更改任何内容，您将需要更新您的框架。

于 2011-01-18T02:59:05.797 回答
0

听起来像magic_quotes 风格的思维。除此之外，至少 magic_quotes 在运行时是 99% 可逆的。您的“清理”数据可能会丢失，这真的很糟糕。

于 2011-01-18T03:08:47.530 回答