Validation Night に行ってきた

Validation Night - connpass

業務でのWeb API開発の参考になればと思い、行ってきました。一週間以上前の話ですが…。エンジニアのトークイベントを聴きに行ったのは今回が初めてで、いろいろ勉強になりました。会場提供、運営、発表してくださった皆様に感謝します。

発表内容

@ockeghemさん SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか

有名な徳丸先生の発表でした。このトークの結論は以下でした。

  • 脆弱性対策はミクロな範囲で実施すること
  • バリデーションは脆弱性の根本対策ではないが、役立つ可能性はある

ミクロな範囲での脆弱性対策とは何かについて、私の理解を書いておきます。 例として、 100万バイト近い長大なパスワードを登録しておくと、 10リクエストほどパスワード認証リクエストを送信するとDoS攻撃できる、という脆弱性の対策について考えます。 このトークで紹介されていた脆弱性のひとつです。

問題が起きるシーケンスは以下になります。

  1. コントローラがアカウント登録リクエストを受け取る
  2. モデルがパスワードを保存する
  3. コントローラが保存されたパスワードを使ったアカウント認証リクエストを受け取る
  4. ★ モデルがパスワードを検証する

　4. が脆弱性のある部分です。モジュール間の関係を図にすると以下になります。

f:id:keshihoriuchi:20141207042515p:plain

ここで、システムのどこかで脆弱性対策のために長いパスワードのリクエストを弾かなければなりません。 どこで弾くべきでしょうか？その答えの根拠が”脆弱性対策はミクロな範囲で実施すること”であり、 答えは実際にパスワードを検証するモジュールになります。

ユーザの利便性を考えればアカウント登録リクエストを受け取るコントローラの時点でバリデーションしておくべきです。 しかし、そのバリデーションだけでは脆弱性対策としては問題です。 なぜなら、脆弱性があるモジュールと異なるモジュールで脆弱性対策すると、 システムの変更によって脆弱性対策が無駄になってしまうリスクが増大するからです。

また、Drupalの脆弱性として上で挙げた脆弱性以外に、Drupaggedonという脆弱性とその対策を紹介していました。 クエリパラメータの連想配列のキーにSQL文を書くとSQLインジェクション攻撃できる、という脆弱性です。 Burp Suite を使った攻撃をライブで披露されていて圧巻でした。

参考

@nippondanjiさん RDBにおけるバリデーションをリレーショナルモデルから考える

漢(オトコ)のコンピュータ道: Validation nightで発表しました。

漢(オトコ)のコンピュータ道の奥野さんの発表でした。発表の要旨は以下だと理解しました。

  • バリデーションはRDBではなくアプリの責任でやりましょう
  • RDBにあるのはバリデーションではなく制約です
  • リレーショナルモデルは集合論に基づくデータモデルです。リレーショナルモデルで解決できる適切な制約を与えましょう
  • 制約の例として型やCHECK制約があります

CHECK制約を知らない情弱だったのですが、Wikipediaによると、保存できるデータを述語で指定する制約のようです。MySQLには無い機能だそうです。

@eiryuさん Javaでのバリデーション 〜Bean Validation篇〜

Validation NightでBean Validationについて発表してきた #v_night - コードつれづれ

JavaのBean Validationというアノテーションでバリデーションする仕組みの紹介でした。Java SEは結構触るのですがJava EEは触ったことがない私としては、Lombokの@NonNullのすごいやつだと理解しました。

本題とは関係ない箇所で個人的にはテストメソッド名が、

  • public void validate_<正常/異常>系_<テスト内容(日本語)>()

となっていたのが、なるほどと思いました。

@tokuhiromさん Webアプリケーション開発におけるValidationの変遷。今日求められているValidationとはなにか?

Validation Night で話してきた - blog.64p.org

Web アプリケーションにおいて Client, Controller, Model のどこでバリデーションすべきかについての発表でした。特に興味深かった主張は以下3点でした。

  • 専用Client以外でAPIを叩かない場合、ClientでValidationできる異常値のAPIへのリクエストは不正アクセスと考えてよいはず。なので、APIがエラーの説明を丁寧に返す必要は無いのでは？
  • Server側が開発できてからClient側を開発するプロセスになっている場合、Client側のスケジュールがカツカツになりやすい。なので、Client側の開発が楽できるようにコミュニケーションの手段として、エラーの説明を親切にしている
  • JSON Schema は複雑なのでClient開発側が読んでくれない気がしている。そこで、Bean Validationのようなフォーマットがよいと思っている

参考

@side_tanaさん jQueryのバリデーション

jQuery Validation Pluginというプラグインが非常に良いという発表でした。ただし、inputタグが動的に増えるような場合だと上手くいかないらしいです。

@studio3104さん focuslight-validator で Sinatra Application の ヴァリデーション

Validation Night で focuslight-validator の紹介をしてきたよ - Studio3104::BLOG.new

focuslight-validatorというsinatraなどで使えるバリデーションライブラリの紹介でした。↑のブログにも書いてあるのですが、発表を聞いたときはfocuslight専用のバリデーションの仕組みなのかと思いました。便利そうなので使ってみたいですね。

@kyo_agoさん WebApplicationフロントエンドValidation

WebApplicationフロントエンドValidation

フロントエンドでのユーザビリティのためのバリデーションについての発表でした。 バリデーションのロジックをフロントエンドとバックエンドで集約するために、バリデーション専用のAPIをバックエンド側に用意するという提案でした。

ネットワークやサーバの負荷が増えるので、使いどころが難しそうな気がしますが、簡単なフォームならあまり問題にならないそうです。

@shigemk2さん 自作JSライブラリでvalidationをごにょごにょする

自作JSライブラリでvalidationをごにょごにょする！ @shigemk2

正規表現を毎回手で書いているとミスが発生しやすいのでライブラリ化した、という発表でした。

@kbaba1001さん Rails Context Validation

ActiveRecord でのバリデーションにおいて、コントローラから渡ってきた条件に基づいて、バリデーション実行するしないを変更するライブラリの紹介でした。

このライブラリを使うと、ビューとモデルが密結合になってしまう問題や、複雑な条件に対応できない問題に触れていました。

ちょくちょく牧場で現実逃避するマイブームに触れて笑いを取っていて、上手いなと思いました。

その他

Twitterでは、どこでバリデーションすべきかについて、以下のJxckさんのツイートが支持を集めていました。