2017年度版 OWASP TOP 10 で変るWebセキュリティのルール

(更新日: 2017/05/25)

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種類しかありません。

  • 正しい入力
  • 入力ミス
  • 不正な入力

参考:入力値の種類は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などのネットワークファイアーウォールを利用することになります。

 

どのように攻撃に”対応”する必要があるのか?

基本的には

  1. 入力バリデーションを行い
  2. 不正な入力を行ったユーザーの
    1. IPアドレス、IP領域をブロックする
    2. アカウントをロックする

を行います。これらの処理は自動的に行われることが望ましいですが、手動で対応する方法も記載されています。

不正な入力値以外にも

  • 頻繁すぎるリクエスト
  • 一般的でない入力値(例:名前に<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的な位置付けで記載されていますが、入力バリデーションはアプリで行うモノです。

 

Comments

comments