メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ（サーバー側）の入力バリデーションについて議論した内容を簡単に紹介します。
どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。
とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか？参考になるので楽しんで議論しています。
議論の概要
私「入力バリデーションはアプリケーションの一番外側の信頼境界でするべきモノですよ」
彼「そんなアホな話があるか。入力バリデーションはモデルでするのが常識だろ。頭おかしいんとちゃうか？」
私「モデルだとソフトウェアの信頼境界の中に入ってからのバリデーションになるから、遅過ぎでダメですよ」
彼「はあ？モデルで集中的にバリデーションするのが当たり前やろ。世の中のフレームワークは全部そうなっとるわ」
私「モデルでバリデーションは遅すぎるだけが問題ではなく、基本DBに保存するデータが対象で全ての入力データがバリデーションできないのが問題ですよ」
彼「だから頭おかしい、って言ってだんだよ。そんなもんはフレームワークのフォームバリデーションでやるのが常識中の常識やぞ」
（この種の誤解をしている人に”何処で”対処するのか説明しても、ほぼ無意味であったことを失念していました。”何処で”ではなく”何を”バリデーションする必要があるのか確認すべきでした。国／人種を越えて同じ論点で攻めないと通用しないとは面白いです。名前からすると”彼”はトルコ系ドイツ人だと思います。）
私「アプリケーション境界での入力バリデーションはGET、POST、HTTPヘッダー、当然Cookieも、全てのデータをバリデーションするモノなのだけど？フォームバリデーションで全部やっている？」
彼「オレのバリデーションは完璧だ。”多層防御”って言葉も知らんアホには分からんだろうけどな！」
（多層防御と聞いて嫌な予感がしてくる）
私「”多層防御”ってどんな多層防御をしているのでしょうか？」
（どうも私が多層防御をよく解っていない、と勘違いしたらしく）
彼「アプリケーションレベルで入力バリデーションせなあかん！とか言ってるアホは多層防御も知らんのか。おととい来やがれ(笑)」
（凄い自信に呆れつつ、嫌な予感を確かめるべく）
私「君のようなタイプの有能な開発者がどんな多層防御しているのか、教えてくれる？」
（自信満々でとあるURLを送ってくる）
彼「このURLにアクセスしてみろ。不正なIDだと全部はじかれるんだよ」
（試してみるとWebアプリファイアーウォールのエラーが！悪い予感的中。ブラックリスト型のWAFだと分りつつ）
私「WAFだね。そのWAFはホワイトリスト型で全部の入力をバリデーションしているの？」
（どうもブラックリスト型対策＆WAFの信者のようで）
彼「そんな非効率なことするかよ！客からアプリがおかしな動作をするのがあるぞ、って言われた時にだけするんだよ」
（絶句。。。）
私「Webアプリ開発者なら全部の入力仕様を解ってるからホワイトリスト型のバリデーションが効率的にできるけどWAFだと難しい。
ネットワークの知識があるなら、会社レベルのファイアウォールをブラックリスト型で作って問題がある度にルールを追加、なんてする技術者ならクビだろ？
君は全部のパラメーターをバリデーションしていない。アプリの動作がおかしくなるからWAFで対策、って全然ダメでしょ。
Webアプリでなら開発者が入力データ仕様を知っている。全て確実にバリデーションできるよ、”入り口”で。しかもWAFで作るより遥かに効率的かつ正確に。
Webアプリで入力データ検証するなら簡単にスケールアウトもできるし、その上より確実な入力バリデーションができるのに、WAFだけ、っておかしいでしょう？」
この説明で理解ったらしく、返信が来ませんでした。自信満々だった彼のプライドが心配です。
簡略化したり、ダーティーワードをマイルドにしたりしましたが、大筋ではこのようなやり取りでした。
入力バリデーションのやり方の誤解は国際的
国は違えど同じようなトンデモな勘違いをしている開発者は居るものです。ちょっと考えれば非効率なことをしている、と理解るのにどうして自信満々なのか理解に苦しみます。
WAFを導入済みということは結構なお金を使ったハズです。技術営業からおかしな情報を吹き込まれていたから彼は自信満々だったでしょうか？！
”おかしな常識”は日本でも色々とあります。長年の間、議論相手だった徳丸さんとのやり取りを簡単に紹介します。
このドイツ人の彼もブラックリストが大好きのようですが、日本でも10年前くらいは徳丸さんをはじめ「ブラックリスト対策もホワイトリスト対策と同じセキュリティ対策！」と主張する人が少なくありませんでした。というより一部のコミュニティでは”常識”だったようです。流石にこの”常識”を主張する人は居なくなりましたが「入力バリデーションはセキュリティ対策ではない／重要ではない」は今でも結構多いです。
「SQLインジェクション対策にエスケープは要らない」とする主張が変わったのかどうか知りません。少なくとも2013年頃に何時まで経ってもSQLインジェクション脆弱性が無くならない状態を見かねて、プリペアードクエリ／プレイスホルダだけのSQLインジェクション対策はダメ過ぎる対策だ、と強く指摘しました。1
その時点では、まだ”要らない派”だったように思います。2017年のPHPカンファレンスの資料でもエスケープにはほぼ触れられていません。今あるSQLインジェクション脆弱性、No1がエスケープ／バリデーション無しのデータであるにも関わらず。2
知る限りでは2014年から徳丸さんは「入力バリデーションはセキュリティ対策ではない」から「アプリケーション仕様でセキュリティ対策ではないが実施しておくもの」としています。今は最も重要なソフトウェアセキュリティ対策になったのでしょうか？
国の外郭団体のIPAでさえ出鱈目な入力対策をやっと去年くらいに修正した状態です。IPAのあの資料なら「入力データバリデーションはセキュリティではない」と一般開発者が勘違い（セキュリティ専門家は別）しても仕方ありません。国を代表するITセキュリティ機関でここまで酷いのは日本くらいではないのか？と思うところです。
基本原理を無視した異常事態 ｰ ソフトウェアのセキュリティ
プログラムが正しく動作する為には、正しい／妥当なデータが必須条件である、これはプログラムの動作原理です。セキュアなソフトウェア＝正しく動作するソフトウェアです。ブラックリスト型で脆弱性を潰していく、とする考え方では場当たり対策のモグラ叩きになります。
データの妥当性はFail Fast原則（失敗するモノはできる限り早く失敗させる原則）で検証します。失敗を先送りしてしまうと、動作の整合性が取れなくなります。整合性が取れなくなる＝誤作動してしまう、になります。
基本の原理と原則から間違っています。基本がこれだけ長い期間正されないのは異常事態です。
少し脱線しましたが、”当たり前”として主張されているセキュリティ対策／概念が実は出鱈目、それを信じてしまっている、というケースは日本だけではなく世界的ということのようです。
原理的に正しい基礎知識が広く定着するのはいったい何時になるのでしょう？ITセキュリティ対策が重要！とするなら基礎知識である原理と原則が出鱈目である所から直さないと無駄ばかりです。
参考： データバリデーションを大別すると3種類在ります。
-
- 徳丸さんのブログではありませんが、主張の趣旨は概ね同じ「SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか」と私が書いた「完全なSQLインジェクション対策」読み比べればどちらが正しいのかは一目瞭然でしょう。人は間違えるモノなので、見当違いで出鱈目な意見でも多目にみましょう。私も間違えることはよくあります。 ↩
- 識別子や配列のエスケープの必要性を無視して、XMLや正規表現／JSONへのインジェクションはSQLインジェクションではない、という意味のない反論が聞こえてきそうです。私は一貫して他のコンテクストもあるからエスケープが必要と言っています。他のコンテクストにXMLやJSONがあるだけです。個別のDBでデータキャストの問題があったりしますが、そういう問題があるからエスケープが要らない、という議論で”SQLインジェクションに脆弱なコードを書かせる”では出鱈目です。 ↩
