1

让我们想象一下输入在哪里，例如：

<input name="x" />
<input name="y" />
<input name="z" />

如果用户手动（例如，通过使用 FireBug 创建更多具有不同名称的输入）会有任何危害吗？

我问这个是因为我的团队昨天创建了一个规则，您需要手动过滤$_POST数组（例如）以确保其中只有预期的键。foo我个人认为，如果有额外的键，比如and ，不会有任何伤害bar。他们会被忽略，对吧？

此外，我们正在使用 Kohana 3.0 及其 ORM。也许这就是重点？也许 ORM 会对额外的、不需要的键做出不同的反应，并且如果“黑客”猜到“错误”键（也是列），可能会更新数据库中的意外列？

你怎么看？

4

3 回答 3

3

这是一些框架中的一个问题，如 Ruby on Rails 和 ASP.NET MVC，它可以作为批量分配发生。

考虑一个用户帐户模型，其中您有用户名、密码、电子邮件，然后是一个布尔标志，用于指示用户是否为管理员。您构建了一个允许自行注册的表单，并且因为您当然不希望用户允许自己成为管理员，所以您只在表单中包含了前三个字段。但是在这些框架中（除非您禁用它），任何具有特定名称的表单字段（无论它们是否来自实际表单）都将被分配。因此，如果攻击者添加了一个名为 user[admin]=1 的字段，它可能由“魔术”后端分配，并且实际上会对数据产生影响，即使您从未明确处理过该变量。

于 2011-08-16T15:49:51.443 回答
2

Erlend 是正确的，如果你只是$_POST加入 ORM，那么你可能会遇到安全问题，但他对 Kohana 的看法是错误的。从 Kohana 3.* 开始，ORM 方法values()采用第二个参数，它是预期键的数组。

所以，下面的例子

$user = ORM::factory('user');
$user->values($_POST, array('username', 'password')
$save->save();

values() 的源代码

只会使用数组中的用户名和密码字段。

于 2011-08-16T17:04:45.047 回答
1

如果您正在使用某种将所有 POST 变量转换为 SQL 查询的自动化，那么声明可能会有一些问题。我不知道 Kohana 做了什么，但一些框架有一个save_to_database( $data )函数可以从$data表中具有相应字段的变量中选择变量，因此理论上攻击者可能能够通过发送将比预期更多的数据保存到数据库中额外的钥匙。（大多数框架还允许将一组允许的字段传递给防止这种攻击的函数。）

于 2011-08-16T07:46:22.913 回答