Rails4のStrong Parametersはコントローラに置かれたバリデータなのか?

Yasuo Ohgaki (大垣靖男) @yohgaki

@yousukezan バクってるのでは無くAPIの仕様により残念な事になってる、という事ですね。週末に解説のブログを書く事にしますが、Railsの開発者はDOAに置いているのでこうなっているのだと思います。

rryu🐋 @rryu2010

バリデーションを「入力値がvalidかどうかを判定し、判定結果を使ってinvalidな時の処理をおこなうことができるもの」とすると、strong parameterはバリデーションではないなあ。 / “Rails4のStrong …” http://t.co/XzhSD4GMKk

しいたけ @yuroyoro

「ControllerでvalidationなぞMVCのなんたるかをわかっちょらんッ！！」というマサカリで延焼しそう | Rails4のStrong Parametersはコントローラに置かれたバリデータなのか? - Togetter http://t.co/xU7SvWBtqb

Youhei Kondou @dw3w4at

いや、元のスライドのvalidationの説明が間違ってる時点でお前は何を言っているんだ https://t.co/vvLUIic9kK

Youhei Kondou @dw3w4at

と思ったら、なんとかがきさんの脳内辞典にあるバリデーション／妥当性って単語が、そもそも人口に膾炙してるほうのバリデーション／妥当性って単語とまるで違っている説 http://t.co/K2DHEMzLrr 標準語と関西弁の「なおす」ぐらい違うのか…。

山崎良祐 / Ryosuke Yamazaki @nappa

ActiveRecord/Model の validates* を信じてはいけない理由が解せない。理屈としては【そんな奥の方で妥当性検証をするのは正しくない、もっと手前段で検証するべきだ】ということなのだろうけど、十分に手前段だと思うけどなぁ。

山崎良祐 / Ryosuke Yamazaki @nappa

Struts 1.x の FormBean のころは変更対象のデータが同一でも Form 毎に検証ロジックを用意する必要があったし、Form でない入力(CSVとかXMLとか)も当然、別の検証ロジックを用意する必要があった。継承や委譲でなんとか整理したけど限界はあった

山崎良祐 / Ryosuke Yamazaki @nappa

その点 ActiveRecord/Model は単一の妥当性検証で済む。これのメリットはテストがしやすいこと、ロジックの確認をとりやすいところ、rails console からの手操作でも validation がかかること、などなど、いろいろあって、かなりイケてると思う

山崎良祐 / Ryosuke Yamazaki @nappa

Mass Assignment 脆弱性が簡単なミスで起きやすいのが難点だったけど、それも Strong Parameters で解決したし、やっぱ ActiveRecord/Model 最強ですよ、と思う

山崎良祐 / Ryosuke Yamazaki @nappa

ActiveRecord/Model で値の妥当性検証をするのは遅すぎる、もっと手前段で検証するべきだ、というなら、別のフレームワーク(たとえば Struts 1.x の FormBean)と比べてどれだけのリスクが増え、どれだけのリスクが軽減されているかを考えるべきだと思う

Youhei Kondou @dw3w4at

validation って、あくまで作っているアプリケーションの要件･仕様を満たす（妥当性）か否かで、ミドルウェア／フレームワークの脆弱な部分をパテ埋めする（セキュリティ対策を施す）か否か、とは直交する概念（≒××、○×、×○、○○、いずれもあり）と考えます。

山崎良祐 / Ryosuke Yamazaki @nappa

個人的な主観では Struts 1.x の FormBean に比べて Rails のほうがはるかに書きやすく、バグも少なく、テストもしやすく、複雑性が低い。リスクが減ったとしても増えたとはとても思えない。

山崎良祐 / Ryosuke Yamazaki @nappa

仮に ActiveRecord, ActiveModel の validate* を信用せず、 Controller で値の妥当性検証を実装したとしても、通るコードの量的は大きな違いなんて無いはずなんですが (数えられるくらいの代入文とメソッド呼び出しが増えるだけで)

Youhei Kondou @dw3w4at

Rails 3 までは、mass assignment 対策は、Model に attr_accessible （更新してよいカラム名ホワイトリスト）または attr_protected （更新したくないカラム名ブラックリスト）を指定していました。あくまで妥当性検査とは別です。

山崎良祐 / Ryosuke Yamazaki @nappa

Rails の Controller は MVC の Controller と完全に一致するものではないですし、Rails の Model と MVC の Model も完全に一致するものじゃないですし。そもそも MVC にキチキチに沿ったフレームワークでろくなのがない気が……

山崎良祐 / Ryosuke Yamazaki @nappa

Rails 4.x の開発なら ActiveRecord, ActiveModel の validate* で値の妥当性検査をして、Controller で Strong Parameters を使い、必要に応じて WAF を入れればいいんじゃないでしょうか

山崎良祐 / Ryosuke Yamazaki @nappa

WAF は Ruby のインタプリタそのものの脆弱性や、Rails の脆弱性(HTTP Requestを受け取ってからユーザが書いたコードへ渡る直前段までの箇所の脆弱性)や、未発見の脆弱性に備えたい人なら入れたほうがいいですね

Youhei Kondou @dw3w4at

ところが昨年 http://t.co/yf2im4VLLd が起きたことで、「attr_accessible or attr_protected を殆どの人使ってなくね？」「そもそも入力場面毎に更新したいカラムが違うし Model で指定するのがおかしくね？」と見直しの機運が。

Youhei Kondou @dw3w4at

@nappa ActiveRecord/Model は非Web画面からも使える部品なので、例えばバッチプログラムから直にこれらを呼ぶときは、そこが入力部分で全然"奥"ではないですよね。なんとかがきさんは ActiveRecord/Model を Web 以外で使う観点がゼロです。

山崎良祐 / Ryosuke Yamazaki @nappa

@dw3w4at そうそう。それが Rails のうれしいところなんですよね。極力SQL文を叩かずに済ませられるのが。

Youhei Kondou @dw3w4at

そこで、Rails 4 からは Controller に strong parameters という機能を登場させ、そこで mass assignment の制御を行うことに。それ以上でもそれ以下でもないです。

Youhei Kondou @dw3w4at

繰り返しますが、 strong parameters は mass assignment の制御という「セキュリティ要件」のための機能であり、「妥当性検査」とは直交する概念です。

山崎良祐 / Ryosuke Yamazaki @nappa

「多重のセキュリティ」っていいますけど、Model での validation に加えて Controller で似たようなロジックを書いて多重防御だと言うのなら同一インタプリタ上で動いてるだけなので、インタプリタの脆弱性を突かれたら終わりなような。

山崎良祐 / Ryosuke Yamazaki @nappa

どうせ「多重防御」するなら Model で値の妥当性検査を作り、Strong Parameters も使う、っていうRails の流儀通りにひととおりやった上で、WAF(=別実装・別処理系)で防御するほうがよほどマシだと思います。Controller に何かを書くよりは。

山崎良祐 / Ryosuke Yamazaki @nappa

そういえばこのスライドの発表現場でツッコミが入らず、Rails 技術者認定試験の Facebook ページでシェアされ、そこにけっこう「いいね」がついちゃって、さらにシェアまでされてしまったという点について。……どうしたら良かったのでしょうね。