额外的、不需要的 $_POST 键会损害系统吗？
让我们想象一下输入在哪里，例如：
<input name="x" />
<input name="y" />
<input name="z" />
如果用户手动（例如使用 FireBug）创建更多具有不同名称的输入，会有什么危害吗？
我问这个问题是因为我的团队昨天创建了一条规则，您需要手动过滤 $_POST 数组（例如）以确保其中只有预期的键。就我个人而言，如果有像 foo 和 bar 这样的额外键，我并不认为有什么坏处。他们会被忽略，对吗？
此外，我们正在使用 Kohana 3.0 及其 ORM。也许这就是重点？也许 ORM 会对额外的、不需要的键做出不同的反应，并且如果“黑客”猜到“错误”的键（所以列也是如此），也许会更新数据库中意外的列？
你怎么认为？
Lets imagine for where are inputs like:
<input name="x" />
<input name="y" />
<input name="z" />
Can there be any harm if user manually, for example, by using FireBug creates more inputs with different names?
I'm asking this because my team yesterday created a rule that you need to manually filter $_POST array (for example) to be sure that there are only expected keys in it. I, personally, don't see any harm if there would be extra keys like foo and bar. They would be ignored, right?
Also, we are using Kohana 3.0 and its ORM. Maybe that's the whole point? Maybe ORM would react different for extra, unneeded keys and, maybe, update unexpected columns in database if 'hacker' guesses the 'wrong' key (so column as well)?
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是某些框架（如 Ruby on Rails 和 ASP.NET MVC）中的一个问题，在这些框架中，它可能以批量分配的形式出现。
考虑一个用户帐户模型，其中有用户名、密码、电子邮件，然后有一个布尔标志来指示用户是否是管理员。
您构建了一个允许自行注册的表单，并且因为您当然不希望用户允许自己成为管理员，所以您只在表单中包含前三个字段。然而，在这些框架中（除非您禁用它），任何具有特定名称的表单字段（无论它们是否来自实际表单）都将被分配。因此，如果攻击者添加了一个名为 user[admin]=1 的字段，该字段可能由“神奇”后端分配，并且实际上对数据产生影响，即使您从未明确处理该变量。
This is a problem in some frameworks like Ruby on Rails and ASP.NET MVC, where it can occur as mass assignment.
Consider a user account model where you have username, password, email and then a boolean flag for whether or not the user is admin.
You build a form for allowing self-registration, and because you of course don't want users to allow themself to become admin, you include only the three first fields in your form. However in these frameworks (unless you disable it), any form field with a specific name (regardless of whether or not they came from the actual form) would be assigned. So if the attacker added a field called something like user[admin]=1, that might be assigned by the "magic" backend, and actually have an effect on the data, even though you never explicitely handled that variable.
Erlend 的观点是正确的，如果你只是将
$_POST放入 ORM 中，那么你可能会遇到安全问题，但他对 Kohana 的看法是错误的。从 Kohana 3.* 开始，ORM 方法values()采用第二个参数，它是预期键的数组。因此，以下示例
源代码value()
只会使用数组中的用户名和密码字段。
Erlend is correct in the that if you just chuck
$_POSTinto ORM then you're likely to run into security problems, but he's wrong about Kohana. With Kohana 3.* onwards the ORM methodvalues()takes a 2nd argument which is an array of the expected keys.So, the following example
Source code for values()
would only use the username and password fields from the array.
如果您使用某种自动化技术将所有 POST 变量转换为 SQL 查询，则可能存在某些问题。我不知道 Kohana 做了什么，但有些框架有一个 save_to_database( $data ) 函数，可以从表中具有相应字段的 $data 中选取变量，因此理论上，攻击者可能能够通过发送额外的密钥向数据库保存比预期更多的数据。 （大多数框架还允许将允许的字段数组传递给防止此类攻击的函数。）
If you're using some kind of automation that converts all POST variables into a SQL query there might be something to the claim. I don't know what Kohana does but some frameworks have a
save_to_database( $data )function that picks the variables from$datathat have corresponding fields in the table, so in theory the attacker might be able to save more data to the database than they're supposed to by sending extra keys. (Most frameworks also allow passing an array of allowed fields to the function which prevents this kind of attacks.)