OWASP Top 10 - 2017で新規追加、統合されたリスクについて

前回に引き続き、2017年11月に公開されたOWASP Top 10 2017についてご紹介します。今回は、Top 10 - 2017で新規追加、統合されたリスク(A4、A5、A8、A10)についてです。詳しくは、OWASP Top 10 - 2017^*をご覧ください。

OWASP Top 10 - 2017

A1： Injection (インジェクション)
A2： Broken Authentication (認証の不備)
A3： Sensitive Data Exposure (機密データの露出)
A4： XML External Entity (XML外部実態参照)
A5： Broken Access Control (アクセス制御の不備)
A6： Security Misconfiguration (セキュリティ設定のミス)
A7： Cross-Site Scripting (クロスサイトスクリプティング)
A8： Insecure Deserialization (安全でないデシリアライゼーション)
A9： Using Components with Known Vulnerabilities (既知の脆弱性を持つコンポーネントの使用)
A10： Insufficient Logging & Monitoring (不十分なロギングとモニタリング)

A4 - XML External Entity (XML外部実態参照)

概要

古い、または設定が不十分なXMLプロセッサの多くは、XMLドキュメント内の外部実態参照を評価します。外部実態参照は、ファイルのURIハンドラ、内部ファイル共有、内部ポートスキャン、リモートコード実行、DoS攻撃を用いた内部ファイルの暴露に使用される可能性があります。

脆弱性有無の確認方法

アプリケーション、具体的にはXMLベースのWebサービスやダウンストリームインテグレーションは、次のような場合、攻撃に脆弱である可能性があります。

• アプリケーションが、特に信頼されないソースからXMLを直接受け入れるか、XMLのアップロードを受け入れる、もしくはXMLドキュメントの中に信頼されないデータを挿入し、XMLプロセッサによって構文解析される
• アプリケーションもしくはSOAPベースのWebサービスのXMLプロセッサが、文書型定義(DTD)を使用可能である。DTD処理を無効にするための厳密なメカニズムはプロセッサによって異なるので、OWASP Cheat Sheet 'XXE Prevention'などのリファレンスを参考にすることを推奨する
• もし、アプリケーションがフェデレーションセキュリティやシングルサインオン(SSO)目的で識別処理にSAMLを使用しているなら、SAMLはIDアサーションのためにXMLを使用しており、脆弱な可能性がある
• もしアプリケーションがバージョン1.2より前のSOAPを使用している場合、XML実態参照がSOAPフレームワークを通して実行されているのなら、XXE攻撃の影響を受けやすい
• XXE攻撃に脆弱であることは、アプリケーションがBillion Laughs攻撃を含むDoS攻撃に脆弱である可能性が高いことを意味する

防止方法

XXEを識別し、軽減するためには、開発者のトレーニングが不可欠です。加えて、XXEを防止するためには以下が必要です。

• 可能であるなら常にJSONなどの複雑さの低いデータフォーマットを使用し、機密データのシリアライズ化を避ける
• アプリや下層のOSで使用しているXMLプロセッサとライブラリのすべてにパッチを適応する、もしくはアップグレードする。依存関係チェッカーを使用する。SOAPを1.2以上のバージョンにアップデートする
• OWASP Cheat Sheet 'XXE Prevention'のように、アプリケーション内のすべてのXMLパーサでXML外部実態参照とDTD処理を無効にする
• XMLドキュメント、ヘッダ、ノード内の悪意あるデータを防ぐために、ポジティブな(ホワイトリストを用いた)サーバ側の入力値検証、フィルタリング、サニタイジングを実装する
• XMLやXSLファイルのアップロード機能がXSDバリデーションや類似のものを用いて受信したXMLを検証していることを確認する
• SASTツールはソースコード内のXXEの検出を手助けするが、多くのインテグレーションを伴う巨大で複雑なアプリケーションでは、手動のコードレビューが最も良い選択肢である

もしこれらの制御が不可能な場合、XXE攻撃を検知、監視、ブロックするためにバーチャルパッチの適用、APIセキュリティゲートウェイもしくはWAFの導入が考えられます。

攻撃シナリオ例

組み込みデバイスの攻撃を含む、多くのパブリックなXXEの問題が発見されました。深くネストされた依存関係を含む、多くの予期しない場所でXXEは発生します。許可されるのであれば、最も簡単な方法は悪意あるXMLファイルをアップロードすることです。

シナリオ①：攻撃者はサーバからのデータ抽出を試みます

シナリオ②：シナリオ①のENTITY行を以下のように変更することで、攻撃者はサーバのプライベートネットワークを調査します

シナリオ③：攻撃者は潜在的に終わりのないファイルを含めることにより、DoS攻撃を試みます

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

概要

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

脆弱性有無の確認方法

アクセス制御は、意図された権限外でユーザが行動できないようにポリシーを強制します。一般的に、アクセス制御の不備は認可されていない情報の開示、すべてのデータの改ざんや破壊、ユーザの制限外のビジネス機能の実行に繋がります。一般的なアクセス制御の脆弱性には以下が含まれます。

• URL、内部のアプリケーションの状態、HTMLページの改ざんや単にカスタムAPI攻撃ツールを使用することによって、アクセス制御のチェックを回避すること
• プライマリキーを他のユーザレコードに変更することを許すことで、他の誰かのアカウントを表示したり編集したりすることを許してしまうこと
• 権限昇格。ログインしないでもユーザとして行動すること、もしくはユーザとしてログインしたときに管理者として行動すること
• 権限昇格させるためのJSON Web Token(JWT)アクセス制御トークン、Cookieやhiddenフィールドの再送や改ざん、もしくはJWT無効化の乱用などのメタデータ改ざん
• 認可されていないAPIアクセスを許可するCORSの誤設定
• 認証されていないユーザの認証されたページへの強制ブラウジング、もしくは一般ユーザの特権ページへの強制ブラウジング。POST、PUT、DELETEに関するアクセス制御が欠如しているAPIへのアクセス

防止方法

アクセス制御は、攻撃者がアクセス制御のチェックやメタデータを改ざんすることが出来ないような、信頼されたサーバサイドのコードやサーバレスAPIで実施されている場合に限り効果的です。

• パブリックリソースを例外として、デフォルトでは拒否する
• アクセス制御メカニズムを1回実装し、アプリケーションの至る所でそれを再利用する。CORSの使用の最小化を含む
• モデルとなるアクセス制御は、ユーザがあらゆるレコードを作成、読み取り、更新、削除することを許可するよりはむしろ、レコードのオーナーシップを強制するべきである
• 固有のアプリケーションビジネス制限の要件は、ドメインモデルによって実施されるべきである
• Webサーバのディレクトリリスティングを無効にし、Webルート内にファイルメタデータ(.git のような)やバックアップファイルが存在しないことを確認する
• アクセス制御の失敗をログに記録し、適切な時に(度重なる失敗など)、管理者に警告を上げる
• 自動攻撃ツールからの被害を最小限にするためにAPIとコントローラーアクセスのレートリミットを設定する
• JWTトークンは、ログアウト後にサーバ上で無効化されるべきである

開発者とQAスタッフはアクセス制御の機能的なユニットテストと統合テストを盛り込むべきです。

攻撃シナリオ例

シナリオ①：アプリケーションがアカウント情報にアクセスしているSQL呼び出しで未検証のデータを使用する

攻撃者は、ブラウザ上で"acct"パラメータを変更し、任意のアカウント番号を送信します。適切に検証されていない場合、攻撃者は任意のユーザアカウントにアクセスすることができます。

シナリオ②：攻撃者は単にターゲットURLに強制ブラウジングを行います。その管理用ページにアクセスするためには管理者権限が必要です。

認証されていないユーザがどちらのページにもアクセスできる場合は、脆弱性があります。また、非管理者が管理ページにアクセスできる場合も脆弱性があります。

A8 - Insecure Deserialization (安全でないデシリアライゼーション)

概要

安全でないデシリアライゼーションは、しばしばリモートコード実行につながります。たとえデシリアライゼーションの欠陥がリモートコード実行の結果とならなかったとしても、リプレイ攻撃、インジェクション攻撃、権限昇格攻撃を含む攻撃を実行するために使用される可能性があります。

脆弱性有無の確認方法

もし、攻撃者によって提供された悪意のあるもしくは改ざんされたオブジェクトをデシリアライズするなら、アプリケーションとAPIは脆弱です。これは以下の2つの主な攻撃種類へとつながる可能性があります。

• オブジェクトとデータストラクチャに関連する攻撃
  もし、デシリアライゼーション中、もしくはデシリアライゼーション後にアプリケーションの挙動を変えることができるクラスが利用可能ならば、攻撃者はアプリケーションロジックを改ざんしたり任意のリモートコード実行を達成したりする
• アクセス制御に関連する攻撃といった典型的なデータ改ざん攻撃
  既存のデータストラクチャは使用されるが、コンテンツが変更される

シリアライゼーションは以下のような目的で、アプリケーションで使用されているかもしれません。

• Remote/Inter-process Communication (RPC/IPC)
• ワイヤプロトコル、Webサービス、メッセージブローカー
• キャッシュ/永続性
• データベース、キャッシュサーバ、ファイルシステム
• HTTP Cookie、HTMLフォームパラメータ、API認証トークン

防止方法

唯一の安全なアーキテクチャパターンは、信頼されていないソースからのシリアライズされたオブジェクトを受け入れない、もしくはプリミティブデータ型のみを許可するシリアライゼーション手法を使用することです。
もしそれが可能でなければ、以下の1つ以上の実装を検討してください。

• 悪意のあるオブジェクトの生成やデータ改ざんを防止するために、シリアライズされたオブジェクトにデジタル署名を付加するなどの完全性チェックを実装する
• 一般的にコードは定義可能なクラスのセットを期待するため、オブジェクト生成前のデシリアライゼーションの間に、厳密な型制限を実施する。本テクニックへの回避は既に実証されているため、本テクニックだけに頼ることは推奨されない
• 可能ならば、低い権限の環境でデシリアライズするコードを分離して実行する
• 受信する型が期待される型でない場合、もしくはデシリアライゼーションが例外を投げる場合など、デシリアライゼーションの例外と失敗をログに記録する
• デシリアライズするコンテナやサーバから送受信されるネットワーク接続を制限もしくは監視する
• デシリアライゼーションを監視して、ユーザが頻繁にデシリアライズする場合、警告を上げる

攻撃シナリオ例

シナリオ①：
Reactアプリケーションは、Spring Bootマイクロサービスのセットを呼び出します。関数型プログラマは、コードを不変な状態に努めようとして、彼らが考え出した解決策は、ユーザ状態をシリアライズし、リクエスト毎にそれを送受信することです。攻撃者は、"R00" Javaオブジェクトシグネチャに気付き、アプリケーションサーバ上でリモートコード実行を達成するために、Java Serial Killerツールを使用します。

シナリオ②：
PHPフォーラムは、PHPオブジェクトシリアライズ処理を使用して、ユーザのユーザID、ロール、パスワードハッシュ、他の状態を含む"super" Cookieを保存します。

攻撃者は、自身に管理者権限を付与するために、シリアライズされたオブジェクトを変更します。

A10 - Insufficient Logging & Monitoring (不十分なロギングとモニタリング)

概要

不十分なロギングとモニタリングは、インシデントレスポンスとの統合の欠如や効果のない統合と組み合わさると、攻撃者によるさらなるシステムへの攻撃、持続性の維持、より多くのシステムへの攻撃やデータの改ざん、抽出、破壊を許すことになります。セキュリティ侵害の研究のほとんどは、検出に200日以上の時間がかかっていることを示しており、一般的に、内部プロセスやモニタリングよりはむしろ外部の関係者によって検出されています。

脆弱性有無の確認方法

不十分なロギング、検出、モニタリングおよび迅速なレスポンスの不足はいつでも発生します。

• ログインの成功/失敗、高価値なトランザクションなどの監査可能なイベントが記録されていない
• 警告とエラーが生成されない、不十分である、もしくは不明瞭なメッセージが生成される
• 不審な行動がないかアプリケーションとAPIのログが監視されていない
• ログがローカルにのみ保存されている
• 適切なアラートのしきい値とレスポンスのエスカレーションプロセスが存在しないもしくは効果的ではない
• DASTツール(OWASP ZAPなど)によるペネトレーションテストとスキャンが警告を発生させない
• アプリケーションがリアルタイムやほぼリアルタイムでアクティブな攻撃を検知、エスカレート、もしくはアラートすることができない

もしユーザや攻撃者にロギングや警告のイベントを把握できるようにするならば、情報漏えいに脆弱です(A3: 2017 - Sensitive Data Exposure (機密データの露出)参照)。

防止方法

アプリケーションによって格納もしくは処理されるデータのリスクによって、以下を実施します。

• 不審なアカウントもしくは悪意あるアカウントを識別するために、十分なユーザコンテキストと共に、全てのログイン、アクセス制御の失敗、サーバ側の入力データ検証の失敗が記録されることを確認し、遅れて発生するフォレンジック分析のために、十分な時間保管しておく
• ログが集中型ログ管理ソリューションによって容易に処理できる形式で生成されていることを確認する
• 高価値なトランザクションが、不可のみ許可されるデータベーステーブル、もしくはそれに類似するものなどといった改ざんや削除を防止するための完全性制御を持った監査証拠機能を持っていることを確認する
• タイムリーに不審な行動が検出、対応されるような効果的なモニタリングとアラートを設ける
• NIST 800-61 rev 2以降などのインシデントレスポンスと復旧計画を設けるもしくは採用する

OWASP AppSensorなどの商用やオープンソースのアプリケーション保護フレームワーク、ModSecurity with the OWASP ModSecurity Core Rule SetなどのWebアプリケーションファイアウォール、カスタムダッシュボードとアラート機能を持つログ相関ソフトウェアなどが存在します。

攻撃シナリオ例

シナリオ①：
小さなチームによって管理されているオープンソースプロジェクトのフォーラムソフトウェアは、そのソフトウェア内の脆弱性が悪用され、ハッキングされました。攻撃者は、次のバージョンとすべてのフォーラムコンテンツが含まれている内部のソースコードリポジトリを消去することができました。ソースコードは復旧可能でしたが、モニタリング、ロギング、アラートの不足ははるかに悪いセキュリティ侵害へとつながりました。フォーラムソフトウェアのプロジェクトは、この問題により、アクティブでなくなりました。

シナリオ②：
攻撃者は、よくあるパスワードを使用しているユーザがいないかスキャンを使用します。彼らはこのパスワードを使用してすべてのアカウントを奪うことが可能です。他のすべてのユーザにとっては、このスキャンは1度だけログイン失敗したということのみ残します。数日後、この事が異なるパスワードで繰り返されるかもしれません。

シナリオ③：
報道によると、主要なアメリカの小売業者は、添付ファイルを解析するマルウェア解析のサンドボックスを持っていました。そのサイドボックスソフトウェアは、潜在的に望ましくないソフトウェアを検知しましたが、だれもこの検知に応答しませんでした。そのサンドボックスは、不正なカード取引に起因するセキュリティ侵害が外部の銀行によって検出される前に、しばらくの間、警告を上げていました。

おわりに

以上、OWASP Top 10 - 2017で新規追加、統合されたリスク(A4、A5、A8、A10)について説明しました。 なお、2013年版から変更されていないリスクやその他参考資料など、今回取り上げなかったものに関しても内容が変更となっている箇所が多々あります。変更点を全て知りたい方はOWASP Top 10 - 2017をご覧ください。

• *Category:OWASP Top Ten Project - OWASP