OWASP Top 10 - 2017 rc1が公開されました

以前、OWASP Top 10 Mobile Risks 2016を紹介したときにOWASP Top 10にも軽く触れましたが、OWASP Top 10は、Webアプリケーションにおいて、OWASP Top Ten Projectが最もクリティカルと考える10種類のセキュリティリスクをまとめたものです。そのOWASP Top 10が更新され、OWASP Top 10 - 2017 rc1が公開されたので2013年版との変更点を簡単にご紹介したいと思います。詳しくは、以下のリンクからOWASP Top 10 - 2017 rc1をご覧ください。

OWASP Top 10 - 2017 rc1

A1： Injection(インジェクション)
A2： Broken Authentication and Session Management(認証とセッション管理の不備)
A3： Cross-Site Scripting(クロスサイトスクリプティング)
A4： Broken Access Control(アクセス制御の不備)
A5： Security Misconfiguration(セキュリティ設定のミス)
A6： Sensitive Data Exposure(機密データの露出)
A7： Insufficient Attack Protection(不十分な攻撃保護)
A8： Cross-Site Request Forgery(クロスサイトリクエストフォージェリ)
A9： Using Components with Known Vulnerabilities(既知の脆弱性を持つコンポーネントの使用)
A10： Underprotected APIs(保護されていないAPI)

OWASP Top 10 - 2013からの変更点

OWASP Top 10 - 2013からの変更点のまとめは以下の通りです。

1. 2013-A4、2013-A7を2017-A4に統合
   OWASP Top 10 - 2007で、アクセス制御に関するリスクへの注意をより向けるために、リスクが2つに分割されましたが、今回の更新で再度統合されました。理由は、「分割する必要をもう感じない」とのことです。
2. 2017-A7を新規追加
   データ呼び出しに基づいて、アプリケーションとAPIの大部分は、手動攻撃と自動攻撃の両方を検出、防止、応答するための基本的な能力が欠けています。また、アプリケーションとAPIの管理者は攻撃から保護するために素早くパッチを適用する必要があります。これらの理由から、本カテゴリが追加されました。
3. 2017-A10を新規追加
   最近のアプリケーションとAPIは、何らかのAPI(SOAP/XML、REST/JSON、RPC、GWTなど)に接続するブラウザやモバイルアプリのJavaScriptなどのリッチクライアントアプリケーションを含んでいることが多くなっています。しかし、これらのAPIは大抵保護されておらず、また多くの脆弱性を含んでいるため、この新たな主要問題に焦点を当ててもらうことを目的として、本カテゴリが追加されました。
4. 2013-A10を削除
   本カテゴリは、問題の認知度を上げるためにOWASP Top 10 - 2010で追加されました。しかしながら、データを見る限りこの問題は予想していたほど普及していません。そのため、OWASP Top 10 - 2017 rc1では削除されました。

それでは、変更されたカテゴリ(A4、A7、A10)について内容を簡単にご紹介します。

A4 - Broken Access Control(アクセス制御の不備)

概要

本問題は、認証されたユーザの権限制御が適切に実施されていない際に発生します。攻撃者は、権限を持っていない機能やデータへアクセスするために、他のユーザアカウントへのアクセス、機密ファイルの閲覧、他のユーザデータの改ざん、アクセス権の変更などの欠陥を悪用します。

脆弱性有無の確認方法

本問題の有無を確認する最善の方法は、全データと機能参照が適切に保護されているかを検証することです。

1. データ参照の場合
   アプリケーションは、ユーザがそのデータに対して権限を持っていることを保証するために、参照マップやアクセス制御チェックを用いてユーザが権限を持っていることを保証しているか
2. 非公開関数要求の場合
   アプリケーションは、ユーザが認証されていることや、その機能を使用するために必要な役割や権利を持っていることを保証しているか

アプリケーションのコードレビューを行うことで、これらの制御が正確に実装されているかどうか、必要な場所に実装されているかどうかを検証することができます。また、アクセス制御の問題は、一般的に自動化ツールでは検出できないため、手動テストによる確認が効果的です。

防止方法

各機能や各タイプのデータ(たとえば、オブジェクト番号やファイル名)を保護する方法を選択する必要があります。

1. アクセスのチェック
   信頼できないソースからの直接参照には、ユーザが要求したリソースの権限があるかどうかを確認するためのアクセス制御チェックが必要
2. ユーザやセッションごとの間接オブジェクト参照
   攻撃者が権限を持っていないリソースへの直接参照を防止
3. 自動検証
   適切な認可配備を検証するために自動化を活用

A7 - Insufficient Attack Protection(不十分な攻撃保護)

概要

ほとんどのアプリケーションとAPIは、手動攻撃と自動攻撃の両方を検出、防止、応答するための基本的な能力が欠けています。攻撃保護は、基本的な入力検証をはるかに超えており、攻撃者の試行を自動的に検出、ロギング、応答、ブロックすることも必要です。アプリケーションの管理者は、攻撃から守るために素早くパッチを適用する必要もあります。

脆弱性有無の確認方法

攻撃を検出、応答、ブロックすることで、アプリケーションを悪用することが非常に困難になりますが、そのような保護を持っているアプリケーションやAPIはほとんどありません。攻撃検出や応答が実装されていなければ、明確にわかります。手動攻撃を試すか、スキャナを実行して脆弱性があるかどうか確認してみてください。また、重大な脆弱性が発見されたとき、仮想パッチや実際のパッチをすぐ適用できない場合は、攻撃にさらされることになります。

防止方法

十分な攻撃保護のための目標として、以下の3つがあります。

1. 攻撃検出
   正規ユーザで行えないことが起こっていないか(例えば、正規クライアントが生成できないような入力)、一般ユーザが行わない方法でアプリケーションが使用されていないか(例えば、アクセス速度が非常に速い、普通ではない入力、普通ではない使用パターン、リクエストの再送)を確認してください。
2. 攻撃への応答
   ログと通知はタイムリーな応答に欠かせません。リクエスト、IPアドレス、IP範囲を自動的にブロックするかどうかを決定し、不正なユーザアカウントを無効にするか監視するかを検討してください。
3. 迅速なパッチ適用
   1日で重要なパッチを適用できない場合は、HTTP通信、データフロー、コード実行を解析して仮想パッチを展開してください。

A10 - Underprotected APIs(保護されていないAPI)

概要

最近のアプリケーションは、何らかのAPI(SOAP/XML、REST/JSON、RPC、GWTなど)に接続するリッチクライアントアプリケーションやAPI(ブラウザやモバイルアプリのJavaScriptなど)が必要な場合がよくあります。これらのAPIは大抵保護されておらず、多くの脆弱性を含んでいます。

脆弱性有無の確認方法

インジェクション、認証、アクセス制御、暗号化、設定、その他の問題が従来のアプリケーションと全く同様に存在している可能性があるため、APIの脆弱性テストは他のアプリケーションの脆弱性テストと似ている必要があります。しかし、APIは人ではなくプログラムで使用されるように設計されているので、UIが欠けており、複雑なプロトコルとデータストラクチャを使用しています。これにより、セキュリティテストが困難になる可能性があります。
結局のところ、APIがセキュアであるかどうかを知ることは、重要な防御を全てテストする戦略を慎重に選択するということです。

防止方法

APIを保護するための鍵は、脅威モデルと何を守りたいかを理解することです。以下を確認してください。

1. クライアントとAPI間の通信が確実に保護されているか
2. APIの認証スキームが強力であり、全ての認証情報、キー、トークンが保護されているか
3. リクエストで使用しているデータフォーマットは何か、またパーサーの設定が攻撃に対して堅牢か
4. APIが不適切に呼び出されないように保護するためのアクセス制御スキームが実装されているか
5. 全てのフォームのインジェクションに対して保護されているか

セキュリティ解析とテストが全てのAPIをカバーしており、ツールで全てのAPIを効果的に検出して解析できることを確認してください。

リスク要因に関する変更点

OWASP Top10 - 2013

OWASP Top10 - 2017 rc1

OWASP Top 10 - 2013からの変更点のまとめは以下の通りです。なお、A4、A7、A10はリスクそのものが変わっているため、以下に含めていません。

1. A2-認証：普及度が「高」から「中」に変更
2. A3-XSS：検出難易度が「容易」から「普通」に変更
3. A8-CSRF：普及度が「中」から「低」に変更
4. A9-コンポーネント：普及度が「高」から「中」に変更、また検出難易度が「困難」から「普通」に変更

以上、OWASP Top10 - 2013から変更された個所について書かせていただきました。今回ご紹介しなかったカテゴリに関して日本語版をご覧になられたい方は、以下のリンクから2013年日本語版をご覧ください。

Category:OWASP Top Ten Project - OWASP

なお、2013年版から変更されていないカテゴリやその他参考資料など、今回ご紹介しなかったものに関しても多少変更されている箇所もありますので、変更点を全て知りたい方はOWASP Top 10 - 2017 rc1、もしくは7月か8月に公開予定のOWASP Top 10 - 2017をご覧になられてはいかがでしょうか。