在表单中使用隐藏字段是否不安全？
例如
想象一下，我有以下表单，
<%= form_for(@comment) do |f| %>
<%= f.hidden_field :user_id%>
<%= f.hidden_field :article_id%>
<%= f.label :content %><br />
<%= f.text_area :content %>
<%= f.submit %>
<% end %>
我得到了 :user_id 和 :article_id 值：
Comment.new(:user_id => current_user.id, :article_id => @article.id)
当我在浏览器中显示表单时，它看起来像这样：
<form action="/comments" method="post">
<input some_rails_tokens_here />
<!-- THIS AREA HERE-->
<input id="comment_user_id" name="comment[user_id]" type="hidden" value="1" />
<input id="comment_article_id" name="comment[article_id]" type="hidden" value="1" />
<!-- THIS AREA HERE-->
<label for="comment_content">Content</label><br />
<textarea id="comment_content" name="comment[content]"></textarea>
<input type="submit" />
</form>
我的问题是，如果有人更改 post 参数而不是被更改怎么办？ :user_id => 的值1 改为：user_id => 2.与文章相同。
我想相信这是通过 Rails 令牌验证的，但我不确定。
For example
Imagine I have the following form
<%= form_for(@comment) do |f| %>
<%= f.hidden_field :user_id%>
<%= f.hidden_field :article_id%>
<%= f.label :content %><br />
<%= f.text_area :content %>
<%= f.submit %>
<% end %>
I got the :user_id and :article_id values with:
Comment.new(:user_id => current_user.id, :article_id => @article.id)
When I display the form in the browser it will look like this:
<form action="/comments" method="post">
<input some_rails_tokens_here />
<!-- THIS AREA HERE-->
<input id="comment_user_id" name="comment[user_id]" type="hidden" value="1" />
<input id="comment_article_id" name="comment[article_id]" type="hidden" value="1" />
<!-- THIS AREA HERE-->
<label for="comment_content">Content</label><br />
<textarea id="comment_content" name="comment[content]"></textarea>
<input type="submit" />
</form>
My question is, what if someone changes the post parameters and instead of being
the value for :user_id => 1 it is changed to :user_id => 2. The same with the article.
I want to believe that is verified with the rails tokens, but I am not sure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
表单中的隐藏字段并不比来自用户的任何其他数据更安全或更不安全。也就是说，它不应该被完全信任：它来自来自用户，并且对操纵和特殊注入开放。
当数据发送回服务器时，服务器应该验证该数据，而不是仅根据特定的用户可修改上下文就假设该操作是允许/无效的。根据需要，可以使用哈希校验和等方法来高度确信数据没有被篡改（但同样，服务器每次请求都应该验证这一点！）。使用“会话状态”可以使数据远离用户操纵区域，从而完全缓解该问题。
快乐编码。
A hidden field in a form is no more or less secure than any other data that come from user. That is, it should not be trivally trusted: It comes from the user and is open to manipulation and specialty injection.
When the data is sent back to the server, the server should validate that data and not assume that the operation is allowed/invalid just based on a particular user-modifiable context. Depending upon needs, approaches like hash checksums can be used to have a very high degree of confidence that the data was not tampered with (but again, this should be verified by the server each request!). Using "session state" mitigates the problem entirely by keeping the data out of user-manipulation land.
Happy coding.
如果允许来自未注册用户的评论，那么为什么要关心 user_id，如果只允许来自注册用户的评论，那么使用 会话 来跟踪用户，而不是在表单元素中传递 user_id。
并回答您的问题，如果使用隐藏字段不安全，没有适当的健全性检查，即使可见字段也不安全。
If comments from un-registered users are allowed then why bother about the user_id at all, and if comments are only allowed from registered users then use sessions to track the user, instead of passing user_id in a form element.
And to answer your question if using hidden fields is insecure, without proper sanity check even the visible fields are insecure.
如果这些字段的值很关键，那么不要相信用户会按原样返回它们。否则，隐藏字段并不比常规可见字段更安全或更安全 - 如果它位于 HTML 中，则有人可以更改它。
If the value of those fields is critical, then don't trust the user to return them unchanged. Otherwise, a hidden field is no less or no more secure than a regular visible field - if it's in the HTML, someone can change it.
如果没有服务器端检查（包括 HTML 表单和浏览器 cookie），则无法信任从客户端发送到服务器的数据。数据可能被恶意修改或多次发送。
我读过一些有关电子商务网站通过 HTML 表单提交产品价格的故事。廉价用户可以编辑他们提交给服务器的 HTML 表单数据来更改产品价格。
Data sent from the client to the server cannot be trusted without server-side checks (including HTML forms and browser cookies). The data could be maliciously modified or sent multiple times.
I have read stories about e-commerce sites that submitted the product price from an HTML form. A cheap user could edit the HTML form data they submit to the server to change the product price.