Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。追記2:正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10(10番目の脆弱性)「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質(入力検証しない&対応しないアプリは脆弱なアプリ)は変わりありません。このテーマついては既にブログは書いています。このエントリでは追加でQ&Aを記載しています。変るWebセキュリティのルール元々はこのスライドは非公開にするつもりでしたが、公開可能な内容で公開することにしました。Ohgaki開発会社としてはどうすれば良いのか?と質問を頂いたので追記します。誰に責任を負わせるのか?誰が負うべきなのか?基本的な入力バリデーションさえ実装してない場合、対応工数はそれなりの工数が必要になります。(?)にも日本の場合、IPAはセキュアプログラミングではないセキュアプログラミングを長年啓蒙していたり、セキュリティ専門家とされる人の中には入力バリデーションとそれを利用した攻撃防止策を”セキュリティ対策ではない”、”重要なセキュリティ対策ではない”、”好ましいセキュリティ対策ではない”と長年主張されている方もいます。開発会社の方々はこれ(セキュリティ専門家のアドバイスの不備)を利用してお客さまに納得していただくのが、最善のアプローチだと思います。「セキュリティ専門家のアドバイスの脆弱性」として取り扱う。A7に対応できる機能を提供していない(事が多い)セキュリティ専門家は常に「これが悪い、あれが悪い」と指摘する側であることが多いです。今回は指摘される側とされても仕方ないでしょう。要するに「開発会社としての注意義務は払っていたが、フレームワークに問題があったように、セキュリティ専門家のアドバイスに問題があった(ので開発した会社の責任ではない)」というロジックなら通用すると思われます。100%に近いアプリが基本的な入力バリデーションさえ実装していない点も、開発会社として要求される注意義務として「入力バリデーションを実装してない責任」を負わされる可能性を低くすると思われます。基本的な入力バリデーションでカバーできる?セキュアコーディングでいう入力バリデーション(ホワイトリスト型チェック&不正な値で処理を停止&ログを記録)であれば入力バリデーションを実装している場合、最低限の「攻撃防御」はできている。A7で要求される追加の「攻撃防御」はアプリで入力バリデーションしていれば多くの物が簡単に実装できます。入力をチェックしていても、バリデーションではなく「サニタイズ」(不正な入力を変換して受け入れる。デフォルト値を利用するなど)をしている場合は”脆弱”です。モデルでの入力バリデーションでカバーできる?MVCモデルならC(コントローラー)で入力バリデーションすべきです。アプリケーションの入出力の境界で実施すべきだからです。M(モデル、つまりアプリ内部)だと遅すぎます。保存前のバリデーションしかしない場合は、普通の入力バリデーションに比べ、仕組み的にかなり脆弱と言えます。多くの場合、モデルでのバリデーションはホワイトリスト型のバリデーションではなく、単なるエラーチェックレベルのバリデーションが多いです。この場合、全く要求事項を満たしていません。エラー処理の基本は”できる限り早くエラーを検出する”です。不正な入力はそもそも、ソフトウェアは一切受け入れるべきではない、致命的エラーです。これを受け入れて処理してしまう構造は”構造的な問題”があると言えます。入力バリデーションはコントローラーのみで行うモノではないです。モデルで外部サービスなどと通信し入出力がある場合、当然モデルでも入力バリデーションを行います。データ型が一致していることを保証するコードになっていれはOK?いいえ。データ型が一致することを保証するだけでは、一番問題となる”文字列型”のデータバリデーションが不十分です。セキュアプログラミングでは数値は”範囲”もバリデーションします。範囲外の数値は最悪の場合、任意コード実行も許してしまいます。データ型を保証する対策は”非常に弱いバリデーション”でしかありません。入力バリデーションの代わりになるモノではありません。追加機能となる部分の負担は?基本的な入力バリデーションでの処理を越える、IPをブロック、ユーザーログアウトさせる、怪しい入力も検出する、頻繁すぎるリクエストを防止する、などの動作は追加の部分は、「単純に新しい脆弱性タイプ」として「新機能として実装」するが妥当でしょう。これらの動作をアプリケーションで実装しているケースは「入力バリデーションを実装」しているケースより更に少ないと思います。ユーザー負担の機能として実装するのが普通だと思います。セキュリティ標準やセキュリティガイドラインの間違いではないか?基本、間違いはありません。一私企業が作ったガイドラインには不適切なモノもあるかも知れません。IPAが公開していた「セキュアプログラミング講座」がセキュアプログラミングではない問題などもあります。公的なセキュリティ標準/ガイドラインではISO27000やOWASP、SANS、CERTなどは「入力はバリデーションすること」を一貫して最重要セキュリティ対策の1つとして要求してきました。このため、セキュリティ標準やセキュリティガイドラインに不備があった、などとするのは間違っています。このような説明にはリスクがあるので注意が必要です。弊社及び私個人は一貫して「入力バリデーションとそれを利用した防御策」を最重要ソフトウェアセキュリティ対策としてお勧めしてきましたが、「重要なセキュリティ対策を知らず、または誤解して、セキュリティ関連のアドバイス」をしているケースは多く知っています。この場合、ガイドラインなどの間違いではなく、その個人や会社の間違いです。簡単に対応する方法は?PHP向けになりますが、入力バリデーションコードを容易に追加できるモジュールhttps://wiki.php.net/rfc/add_validate_functions_to_filter(残念ながらこのはPHP本体のRFC(機能追加提案)としては棄却されました)を3rdパーティモジュールとして配布予定です。A7が要求する「攻撃防御」をかなり容易に”後付け”できます。紹介エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。yohgaki@ohgaki.net私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。