多くのコメンテーター ( ZDNetなど) は、GitHub のケースの弱点は、Homakov が発見したモデルが脆弱であり、その属性に対して一括割り当てが有効になっていることであると示唆しています。
ただし、問題はこれではなくbefore_filter、コントローラーで a (またはそのようなもの) を使用して、彼が更新したテーブル内の特定の行を管理者または ID を持つユーザーのみが更新できるようにするのに失敗したことだと思いますその行に記載されています。そのようなフィルターがコントローラーに配置されていた場合、モデルの属性が一括割り当て可能であっても、テーブルは攻撃から保護されていたでしょう。
私は正しいですか？
はい、私はあなたが正しいと思います。
このような状況では、認証ジェムを使用することもできます。たとえば、cancan、declarative authorization、heimdallr ...
問題は、使用できることではありません。問題は、特定の状況でそれを使用することを忘れないようにする方法です。たとえば、次のメソッドを持つことができます:check_authorizationすべてのアクションの承認を確認するのに役立ちます。
それについてホミャコフは言います。保護された属性を追加するのが最も簡単な方法です。権限を制限するための解決策が異なっていたため、脆弱性が発見されたのかもしれません。場合によっては、保護された属性を追加すると、API の柔軟性が失われることがあります。
私が理解している限り、この問題は管理者の before_filters チェックとは何の関係もありません。public_keys モデルの user_id を引用した例では、大量割り当てにさらされることになっていない属性が存在していました。
これは、取得するはずの属性のみを確実に取得するためにも使用できるためbefore_filter、セキュリティの別の「レイヤー」として機能することもできます。.slice
最後の注意: 管理者 != 神だと思います。つまり、Homakov がこの問題を悪用して実行できたアクションを実行する権限を持つ Github 管理者は役に立たないということです。