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