为什么对参数哈希进行切片会在批量分配时带来安全问题？

发布于 2024-12-05 15:06:19 字数 694 浏览 7 评论 0原文

防止批量分配安全风险的官方方法是使用 attr_accessible 。然而，一些程序员认为这不是模型的工作（或者至少不仅仅是模型的工作）。在控制器中执行此操作的最简单方法是对 params 哈希进行切片：

@user = User.update_attributes(params[:user].slice(:name))

但是文档指出：

请注意，使用 Hash#except 或 Hash#slice 代替 attr_accessible 清理属性并不能提供足够的保护。

这是为什么？ 为什么参数的白名单切片不能提供足够的保护？

更新： Rails 4.0 将提供强参数，这是对参数的精细切片，所以我猜整个切片的事毕竟没那么糟糕。

原文

The official way of preventing security risks with mass-assignment is using attr_accessible. However, some programmers feel this is not a job for the model (or at least not only for the model). The simplest way of doing it in a controller is slicing the params hash:

@user = User.update_attributes(params[:user].slice(:name))

However the documentation states:

Note that using Hash#except or Hash#slice in place of attr_accessible
to sanitize attributes won’t provide sufficient protection.

Why is that? Why a whitelist-slicing of params does not provide enough protection?

UPDATE: Rails 4.0 will ship strong-parameters, a refined slicing of parameters, so I guess the whole slicing thing was not so bad after all.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我恋#小黄人 2024-12-12 15:06:19

控制器中的 slice 和 except 问题可能与模型中的 accept_nested_attributes_for 结合使用。如果您使用嵌套属性，则需要在所有位置对参数进行切片，然后在控制器中更新它们，这并不总是最简单的任务，尤其是在深度嵌套的情况下。使用 attr_accesible 就不会出现这个问题。

回复收藏 0 原文

卖梦商人 2024-12-12 15:06:19

从 Rails 4 开始，对参数进行切片将是处理批量分配安全性的首选方法。 Rails 核心团队现在已经开发了一个插件来处理这个问题，他们正在致力于集成对嵌套属性和签名表单的支持。绝对值得一看： http://weblog.rubyonrails.org/2012/ 3/21/强参数/

回复收藏 0 原文

爺獨霸怡葒院 2024-12-12 15:06:19

DHH 关于控制器切片与单独白名单的有趣要点：

https://gist.github.com/1975644

class PostsController < ActionController::Base
  def create
    Post.create(post_params)
  end

  def update
    Post.find(params[:id]).update_attributes!(post_params)
  end

  private
    def post_params
      params[:post].slice(:title, :content)
    end
end

评论强调在控制器内管理此内容的需要：

https://gist.github.com/1975644#gistcomment-88369

我个人将 attr_accessible 与 slice 一起应用，以确保没有意外的情况发生。切勿仅依赖黑名单！

Interesting gist from DHH on slicing in controller vs whitelisting alone:

https://gist.github.com/1975644

class PostsController < ActionController::Base
  def create
    Post.create(post_params)
  end

  def update
    Post.find(params[:id]).update_attributes!(post_params)
  end

  private
    def post_params
      params[:post].slice(:title, :content)
    end
end

Comment reinforcing the need to manage this within the controller:

https://gist.github.com/1975644#gistcomment-88369

I personally apply both - attr_accessible with slice to ensure nothing unexpected gets through. Never rely on blacklisting alone!

回复收藏 0 原文

半山落雨半山空 2024-12-12 15:06:19

只需从 params 哈希中删除 :name 即可防止为该操作设置该属性。它仅适用于您记得保护的操作。

但是，这种做法并不能保护您免受使用自动添加的所有关联方法的滥用。

class User < ActiveRecord::Base
  has_many :comments
end

即使您从 params 中删除了 comments 属性，也会让您容易受到设置 comments_ids 属性的攻击。

由于为关联添加了相当多的方法，并且它们将来可能会发生变化，因此最佳实践是使用 attr_accessible 保护模型上的属性。这将最有效地阻止此类攻击。

Just removing the :name from the params hash works to prevent setting that attribute for that action. It works only for the actions you remember protecting.

However, this practice doesn't protect you from abuse using all the methods automatically added for associations.

class User < ActiveRecord::Base
  has_many :comments
end

will leave you vulnerable for someone setting the comments_ids attribute, even when you delete the comments attribute from params.

Since there are quite a lot of methods added for associations, and since they might change in the future, the best practice is to protect your attributes on the model using attr_accessible. This will stop these kind of attacks most effectively.

回复收藏 0 原文

半世蒼涼 2024-12-12 15:06:19

@tokland你最后的评论在某种程度上是不正确的。除非您的网站将浏览器作为数据传入和传出的唯一入口点。

如果您的 Web 应用程序具有 API 或与其他 API 进行通信，则控制器级别的保护会留下漏洞，并且来自其他来源的所有数据都不会被清理或检查。我建议保持原样，在 application.rb 中打开批量分配保护，并改进 ActiveSupport FormHelpers 以像 Django/Python 风格一样工作。

回复收藏 0 原文

~没有更多了~