ruby-on-rails Rails:防止在多态选择下拉列表上分配其他模型

uujelgoq  于 2023-08-08  发布在  Ruby
关注(0)|答案(1)|浏览(93)

我正在实现一个应用程序,其中User模型可以通过Assignment链接对象与零个或多个BusinessUnit对象和/或零个或多个Location对象相关联(如下所示)。

class Assignment < ApplicationRecord
  belongs_to :user
  belongs_to :assignable, polymorphic: true

  validates :user_id, uniqueness: { scope: [:assignable_type, :assignable_id] }
end

字符串
我正在用户编辑页面上执行多个选择下拉菜单来分配位置/业务单位。经过一些研究,我正在使用签名的全局ID,这是基于以下两个指南中非常有用的指导:OneTwo
在后一个指南中,作者非常明确地确保只能分配预期的类(他们的示例中的用户和团队,我的示例中的业务单元和位置)。在前一个例子中,作者Assert当使用签名全局ID时,这是不必要的:
用户可以设置为审查主题的唯一记录是我们在审查表单中包含它们时允许的记录。
问题:哪一个是正确的?直观地说,一个有签名的全局ID(过期,不是幂等的,并且包括时间戳)不能被伪造来引用一个不同的任意类和对象似乎是准确的,但是我想确保我没有错过一个漏洞,因为这是我第一次使用有签名的全局ID。
谢谢你,谢谢

vptzau2j

vptzau2j1#

您的直觉是对的,SGID实际上是不可能伪造的,并且在关联中使用recipient_前缀也增加了一个重要的安全层。我会停止在只是有locate_many_signed(..., only: BROADCAST_RECIPIENT_CLASSES)层增加安全性在那里(即。我认为添加的分组步骤,然后再次循环B_R_C是不必要的)
所以,你可能会问,给定SGID,我们甚至需要only:的东西吗?对此我想说,今天不行。但是应用程序会随着时间的推移而增长和变化,所以增加一层保护似乎是个好主意,以防将来会增加一些你没有预料到的东西。
而FWIW,为此,我可能会命名BROADCAST_RECIPIENT_CLASSES更明显/更令人担忧的东西,比如TAINTED_INPUT_WHITELIST

相关问题