为什么将参数散列切片对批量分配造成安全性问题? [英] Why slicing the params hash poses a security issue on mass-assignment?

问题描述

通过批量分配预防安全风险的官方方法是使用 attr_accessible .但是，一些程序员认为这不是模型的工作(或者至少不是模型的 only ).在控制器中执行此操作的最简单方法是切片 params 哈希:

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))

但是文档指出:

请注意，使用Hash#except或Hash#slice代替attr_accessible 清理属性将无法提供足够的保护.

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

那是为什么? 为什么 params 的白名单切片不能提供足够的保护?

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

更新: Rails 4.0将会强大-parameters ，一种精细的参数切片，所以我想整个切片事情毕竟还算不错.

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.

推荐答案

切片和控制器中的问题可能与模型中的accept_nested_attributes_for一起出现.如果使用嵌套属性，则需要在所有位置上对参数进行切片，然后在控制器中对其进行更新，这并非总是最简单的任务，尤其是在深度嵌套的场景中.使用attr_accesible不会出现此问题.

The problem with slice and except in controller might occur in combination with accept_nested_attributes_for in your model. If you use nested attributes, you would need to slice parameters on all places, where you update them in controller, which isn't always the easiest task, especially with deeply nested scenarios. With using attr_accesible you don't have this problem.

这篇关于为什么将参数散列切片对批量分配造成安全性问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！