Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。追記2:12月現在ではPDF版がリリースされています。現時点ではWebページの内容はドラフト版になっています。Monitoring」になり、緩い要求事項に変更されていますが、基本的な要求事項は変わりません。マトモな入力バリデーションがないと要求されるログと監視機能を提供できません。Project)とはWebシステムのセキュリティ向上を目指す団体です。Standard)標準に強い影響力を持っています。DSS標準ではOWASPなどのセキュリティガイドを参照/実装するように求めています。10はOWASPガイドプロジェクトの中で最も重要なプロジェクトです。今年はその新版が4年ぶりにこの夏公開予定です。この4月からRC版(PDF)が公開されています。Protection(不十分な攻撃防御)が追加された点です。これがWebセキュリティのルールを変える指針になります。Protection(不十分な攻撃防御)とは?RC版のA7は以下のようになっています。10的には攻撃を”検出”しないアプリケーションは脆弱なアプリケーションである攻撃に”対応”しないアプリケーションは脆弱なアプリケーションである脆弱性に”素早く対応”できないアプリケーションは脆弱なアプリケーションであるということになります。:D”)</script>’といった入力があるのに、攻撃を検出/防止もせずエスケープだけしているようなアプリケーションは”脆弱なアプリケーションである”と考えられるようになります。10のA7に記載されている通りです。不正な入力(つまり仕様上あり得ない入力)を検出します。これには仕様に則った厳格な入力バリデーションを利用します。したアプリケーション仕様なら、入力の種類は3種類しかありません。参考:入力値の種類は3種類しかない仕様上あり得ない入力を受け入れる必要性は全くありません。”不正な入力”をアプリケーションレベル(アプリケーション境界)で検出します。セキュアなアプリケーションは、ホワイトリスト型の入力バリデーションを行います。一部の例外を除き、基本的にブラックリストを使用してはいけません。ブラックリスト型の対策はホワイトリスト型の対策に比べ、かなり脆弱だからです。Firewall)も”利用できる”としています。WAFでホワイトリスト型の入力バリデーションを実装するのはかなりの困難を伴います。これは、WAFのルールとアプリケーションの仕様を”同期”させないとならないからです。一般にWAFの管理とアプリケーション開発は別の人が行います。この為、WAFのルールをアプリケーション仕様と同期させることが難しくなります。アプリケーション開発者は”仕様”を知っているので、入力バリデーションを実装するのはアプリケーション開発者が行うと効率的に管理できます。AppSensorも”利用できる”としています。AppSensorは実在するソフトウェアではありません。AppSensorのページトップには、次の記載があります。System)に必要とされる機能を定義したシステム要求定義/仕様定義といった位置付けになります。WAFの場合、スケールさせることが難しく、個々のWebアプリケーションに導入するにもコスト面、管理面で難しいです。ほとんどのAppSensorの攻撃検出防止機能はWebアプリだけで実装できます。基本的には入力バリデーションを実装することになります。過剰なリクエスト制御と制限はWebアプリのみで実装/対応するのは難しいので、iptablesなどのネットワークファイアーウォールを利用することになります。どのように攻撃に”対応”する必要があるのか?基本的には入力バリデーションを行い不正な入力を行ったユーザーのIPアドレス、IP領域をブロックするアカウントをロックするを行います。これらの処理は自動的に行われることが望ましいですが、手動で対応する方法も記載されています。不正な入力値以外にも頻繁すぎるリクエスト一般的でない入力値(例:名前に<script>alert(‘Hacked’)</script>など)普通でない利用パターン(例:外部ドメインからのPOSTリクエストなど)”頻繁すぎるリクエスト”の無効化はアプリケーションで対応できます。効率的に対応するには、iptablesなどのネットワークファイアーウォールを利用可能です。アプリケーションレベルでは”頻繁すぎるリクエスト”の無効化の閾値を低め、ネットワークファイアーウォールでは閾値を高め、に設定すればアプリで”頻繁すぎるリクエスト”を検出しつつ、ファイアーウォールで過剰なリクエストをネットワークレベルで廃除することができます。どのように脆弱性に”素早く対応”するのか?アプリケーションレベルで体系的な入力バリデーションを実装していれば、脆弱性に素早く対応することが可能になります。Struts2がContent-Typeで任意コード実行が可能であった脆弱性はContent-Typeの入力値がRFCに則った入力であることをバリデーションしていれば攻撃不可能でした。フレームワークの補助があった方がやりやすいので、体系的な入力バリデーションをサポートしているフレームワークか、体系的な入力バリデーションを追加し易いフレームワークを利用すると良いでしょう。Struts2のようにHTTPヘッダーの入力バリデーションでさえ困難なフレームワークもあるので、こういったフレームワークは、少なくとも今から採用するのは避ける方が良いでしょう。まとめ2017年以降、OWASP的に入力バリデーションを行っていないWebアプリケーションは脆弱なアプリケーションになります。Protection(不十分な攻撃防御)はフレームワークなどが勝手に対応する脆弱性ではありません。フレームワークが自動処理する入力はフレームワークで対応することが可能ですが、自分が作っているアプリの入力バリデーションは自分で行う必要があります。OWASPの文書が”WAFを利用することができる”としていることからも解るように、アプリケーションの境界、で入力バリデーションすることが重要です。正しい信頼境界線の概念が必要になります。WAFでもOKですが、普通はブラックリスト型の対策にならざるを得ません。コスト面でも運用面でもWAF導入は高くつきます。そもそもWAFを導入できないシステムも多いでしょう。”不十分な攻撃防御脆弱性”がない、よりセキュアなアプリケーションを目指すならしっかりとした入力バリデーションを実装したアプリケーションが必要になります。残念ながら、体感的には世の中の99%のWebアプリケーションは”不十分な攻撃防御脆弱性”を持っています。今年はWebアプリケーション開発者にとって、Webセキュリティが大きく変りだす年になりそうです。(10年以上言い続けて、やっと、変りそうです。)備考:一部の専門家は正反対のことを主張していましたが、本物のセキュリティ専門家は何十年も前から入力バリデーションがセキュリティ対策として重要だと言っています。OWASPも入力バリデーションをセキュアコーディングの一番目の対策として挙げ、アプリケーションに実装することを長年推奨しています。AppSensorの仕様はWAF的な位置付けで記載されていますが、入力バリデーションはアプリで行うモノです。紹介エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。yohgaki@ohgaki.net私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。