OWASP Top 10 2017 のリリースとPCI DSS要件の影響について ...

1) OWASP Top 10 2017 での変更点の概要

ここでは、まず、OWASP Top 10 2017 版で、旧版（2013年版）からどういう変更があったかの概要を紹介します。
OWASP Top 2013年版からの変更点の概要は以下のとおりです（英語原文の和訳になります）。

【新規】2017-A4「XML外部実体参照（XXE）」を追加

OWASP Top 10 を作成するにあたり、セキュリティ事業者から寄せられる診断結果が元になりますが、この項目はSAST（静的アプリケーションセキュリティテスト（≒ソースコード診断））のデータから採用されました。

【新規】2017-A8 「安全でないデシリアライゼーション」を追加
【新規】2017-A10 「不十分なロギングおよび監視」を追加

OWASP Top 10 を作成するにあたり、先見性のある脆弱性カテゴリに対する洞察を求めたところ、500を超える投稿があり以下の2点を採用しました。

2017-A8 「安全でないデシリアライゼーション」

これは、影響を受けるプラットフォームでは、リモートコード実行や機微なオブジェクト操作を許してしまいます。

2017-A10 「不十分なロギングおよび監視」

「不十分なロギングおよび監視」が欠落していると、悪意のある活動やデータ漏えい検知、インシデント対応、デジタルフォレンジクスが阻害または遅れてしまいます。

【統合】2013-A4 「安全でないオブジェクト直接参照」と 2013-A7 「機能レベルアクセス制御の欠落」を 2017-A5 「アクセス制御の不備」に統合

【削除】2013-A8「クロスサイトリクエストフォージェリ（CSRF）」と 2013-A10 「未検証のリダイレクトとフォワード」を削除

「クロスサイトリクエストフォージェリ」は、多くのフレームワークにCSRF防御が含まれ、今回のセキュリティ事業者から寄せられる診断結果が5%であったため、Top 10から外されました。また、「未検証のリダイレクトとフォワード」についても、8％であったため、Top 10から外されました。

（※1）原文中に明示的に言及されていませんが、2013年度版から、全体的に"Web applications"が"Web applications and APIs"に書き換えられています。2017 RC1の時からこうなっていますが、ブラウザ表示のある通常のWebアプリケーションだけではなく、Web UIを持たないAPIについても保護対象に含まれることになると思います。
（※2）2013年版と変わらないTop 10項目についても、ざっと読んだところ内容が変わっている箇所がありました（例えば、2017-A3「機密データの露出」の防止方法でTLSでの経路暗号に加えHSTSによる暗号化強制に関する記述がありました）が、ここではTop 10項目レベルで変更のあった箇所のみ記載します。

2) 新規項目の詳細

OWASP Top 2013年版からの新たに追加された3点の項目の詳細は、以下のとおりです（英語原文の和訳になります）。

2017-A4 「XML外部実体参照（XXE）」

【脆弱性有無の確認】

アプリケーションおよび特定のXMLベースのWebサービスやダウンストリーム統合は、以下の場合、攻撃に対して脆弱であるもしれません。

アプリケーションが、信頼できないソースから直接のXMLやXMLアップロードを受つけていたり、信頼できないデータをXML文書に挿入してXMLプロセッサにパースさせていたりする。

アプリケーションおよびSOAPベースのWebサービス内のXMLプロセッサが、文書型定義（DTD）を有効にしている。DTD処理の無効化の正確な方法はプロセッサごとにより異なるため、 OWASP XXE Prevention Cheat Sheet などの参考資料を参考にすることが推奨されます。

アプリケーションが、統合セキュリティやシングルサインオン（SSO）内の処理を識別するためにSAMLを使用している場合。SAMLは、IDアサーションのためにXMLを使用し、脆弱な可能性があります。

アプリケーションがバージョン1.2より前のSOAPを使用している場合、XML実体参照がSOAPフレームワークに渡されているのであれば、XXE攻撃の影響を受けやすい状態にあります。

XXE攻撃に対して脆弱であることは、サービス不能攻撃に対しても脆弱であることを意味します。

【防止方法】

XXEを特定し低減するためには、開発者トレーニングが最も重要です。それ以外に、XXEを防止するには以下の対策が必要です。

可能な場合はいつでも、JSONのようなあまり複雑でないデータ書式を使用し、機微な情報のシリアライゼーションを避ける。

アプリケーションや下層のOSで利用しているすべてのXMLプロセッサやライブラリを、最新のものになるようパッチを適用するかアップグレードする。依存性チェッカーを使用する。SOAPを1.2またはそれ以降にアップグレードする。

アプリケーション内のすべてのXMLパーサにおいて、 OWASP XXE Prevention Cheat Sheet にあるとおりに、XML外部実体参照およびDTD処理を無効化する。

明確な（「ホワイトリストを用いた」）入力値検証、フィルタリングまたは無害化を実装して、XML文書やヘッダ、ノード内の悪意のあるデータを阻止する。

XMLまたはXSLファイルのアップロード機能において、XSDバリデーションや類似のもので、入力XMLを検証する。

多くが統合されている大規模かつ複雑なアプリケーションでは手動でのコードレビューが最善の方法ですが、SAST（静的アプリケーションセキュリティテスト）ツールを使用すると、ソースコード内のXXEの検出に役立ちます。

これらのコントロールが実施できない場合、XXE攻撃を検知、監視、ブロックするために、仮想パッチやAPIセキュリティゲートウェイ、Webアプリケーションファイアウォール（WAF）を使用することを検討してください。

2017-A8「安全でないデシリアライゼーション」

【脆弱性有無の確認】

アプリケーションやAPIは、攻撃者によってもたらされる悪意のあるまたは書き換えられたオブジェクトをデシリアライズする場合、脆弱です。これは、2つの主要な攻撃のタイプに帰結します。

オブジェクトやデータ構造に関連する攻撃で、攻撃者はアプリケーションロジックを改変するか、デシリアライゼーション中または後にアプリケーションの振舞いを変更できるアプリケーションに対して利用可能なクラスが存在する場合に任意のリモートコード実行を達成します。

既存のデータ構造は使用するがコンテンツは変更されるようなアクセス制御関連の攻撃等の、典型的なデータ書き換え攻撃。

シリアライゼーションは、以下のようなアプリケーションで使用されている可能性があります。

リモートおよびプロセス間通信（RPC/IPC）

無線プロトコル、Webサービス、メッセージブローカー

キャッシュ/パーシステンス

データベース、キャッシュサーバ、ファイルシステム

HTTPクッキー、HTMLフォームパラメータ、API認証トークン

【防止方法】

唯一の安全なアーキテクチャーパターンは、信頼できないソースからのシリアライズされたオブジェクトを受け付けない、またはプリミティブなデータ型のみを許可したシリアライゼーション媒体を使用することです。
もしそれができない場合は、以下を実施します。

シリアライズされたオブジェクトの完全性チェックや暗号化を実装して、悪意のあるオブジェクトの生成やデータ書換えを防止する。

オブジェクトの生成前に、デシリアライゼーションの間に厳密な型制限を強制する。通常は、コードは、定義可能なクラス一式です。この技術の迂回は既に実証されています。

一時コンテナなど、デシリアライズするコードを分離し、非常に低い権限の環境で実行されるようにする。

入力型が予期しない型であったりデシリアライゼーションが例外をスローしたりするような、デシリアライゼーションの例外および失敗を記録する。

デシリアライズするコンテナやサーバーからの受信および送信ネットワーク接続を制限または監視する。

デシリアライゼーションを監視し、ユーザーが絶えずデシリアライズしていれば警告発信する。

2017-A10「不十分なロギングおよび監視」

【脆弱性有無の確認】

不十分なロギング、監視および能動的対応はいつでも起こります。

ログイン成功や失敗、高価値のトランザクションといった監査可能なイベントがログに記録されていない。

警告やエラーが、ログメッセージを生成しないか、不適切または不明瞭なメッセージを生成する。

怪しい活動に対して、アプリケーションやAPIのログが監視されていない。

ログがローカルにしか保管されていない。

アプリケーションで保持されるデータのリスクに応じた警告発信しきい値や対応のエスカレーションが実装されていないか、効果的ではない。

ペネトレーションテストおよびDASTツール（OWASP ZAPのような動的アプリケーションセキュリティテストツール）では、警報を発信しない。

アプリケーションが、リアルタイムまたは準リアルタイムで、活動中の攻撃者に対して検知を実施し、エスカレーションおよび警報発信ができない。

ユーザや攻撃者に対して見えるイベントを記録し警報を発信するのであれば、情報漏えいに対して脆弱です（A3:機密データの露出を参照）。

すべてのログイン、すべてのアクセス制御の失敗、すべての入力値検証の失敗が、怪しいまたは悪意のあるアカウントを特定するのに十分なコンテキストを持ってログに記録できることを確実にする。

ログが集中ログ管理ソリューションで容易に利用しやすい形式で生成されることを確実にする。

高価値のトランザクションには書換えや削除を防止する完全性制御（例えば、データベーステーブルへの追加のみなど）を持った監査証跡があることを確実にする。

効果的な監視および警告発信を確立し、総当たり攻撃といった怪しい活動やビジネス損失（例えば、日または時間単位の制限を超えるトランザクション）を、許容時間内に検知および対応できるようにする。

NIST 800-61 rev2 以降などのインシデント対応および復旧計画を確立または採用する。

OWASP AppSensorのような商用やオープンソースのアプリケーション保護フレームワーク、ModSecurity with the OWASP ModSecurity Core Rule SetのようなWebアプリケーションファイアウォール、カスタムダッシュボードや警報発信機能を持つログ相関分析ソフトウェアがあります。

3) PCI DSS要件への影響について

1)および2)で紹介した変更点が、アプリケーションセキュリティという観点で、PCI DSS要件（バージョン3.2）への影響を考察したところ、直接的な影響を受ける要件は要件6、要件10、要件11となり、このうち対応が必要になるのは要件6、要件11となると想定されます。以下、関連するPCI DSS要件と追加対応内容を示します。追加されたOWASP Top 10項目対応要件対応要否備考 2017-A4 「XML外部実体参照（XXE）」要件6、11要要件6（6.5、6.6）、要件11（11.3）において、追加の対応が必要 2017-A8 「安全でないデシリアライゼーション」要件6、11要（同上） 2017-A10 「不十分なロギングおよび監視」要件10不要要件10（10.4を除く）に既に含まれているため、対応不要

対応が必要な要件および対応内容

要件6.5

ソフトウェア開発プロセスにおいて次のようにして一般的なコーディングの脆弱性に対応する。

開発者に対して一般的なコーディングの脆弱性を回避することを含む安全なコーディング技法について少なくとも年次でトレーニングを実施する。

安全なコーディングガイドラインに基づいてアプリケーションを開発する。

注: 要件6.5.1～6.5.10に挙げられている脆弱性は、このバージョンのPCI DSSが発行された時点の最新の業界ベストプラクティスを踏襲しているが、しかし、脆弱性管理のための業界のベストプラクティスは更新されているため（OWASPガイド、SANS CWE Top 25、CERT Secure Coding など）、現在のベストプラクティスは、これらの要件を使用する必要がある。

要件6.6

一般公開されているWebアプリケーションで、継続的に新たな脅威や脆弱性に対処し、これらのアプリケーションが、次のいずれかの方法によって、既知の攻撃から保護されていることを確実にする。

一般公開されているWeb アプリケーションは、アプリケーションのセキュリティ脆弱性を手動/自動で評価するツールまたは手法によって、少なくとも年 1 回および何らかの変更を加えた後にレビューする

注: この評価は、要件11.2で実施する脆弱性スキャンとは異なる。

Web ベースの攻撃を検知および回避するために、一般公開されている Web アプリケーションの手前に、Webベースの攻撃を自動的に検出・防止する技術的な解決策（Webアプリケーションファイアウォールなど）をインストールする。

要件11.3

少なくとも以下を含むペネトレーションテスト方法を開発し、実装する。

業界承認のペネトレーションテスト方法（NIST SP800-115 など）に基づいている

…（中略）…

アプリケーション層のペネトレーションテストは、少なくとも要件6.5に記載されている脆弱性を含める必要がある

…（後略）…

必要となる対策

【要件6.5、6.6】

評価範囲の事業体でセキュアコーディングルールを定めている場合、「セキュアコーディング規約」や「開発時のセキュアコーディングレビュー」などに今回追加された2つの脆弱性「XML外部実体参照（XXE）」「安全でないデシリアライゼーション」に関する記述や観点を追加し、運用する必要があります。また、WAFによるセキュリティ監視を採用している場合、利用しているWAF機器や監視サービスが、XML外部実体参照（XXE）」「安全でないデシリアライゼーション」の攻撃検知が可能であること確認することも必要になります。 ※ なお、削除された2件の脆弱性「クロスサイトリクエストフォージェリ（CSRF）」「未検証のリダイレクトとフォワード」については、あくまでも今回のTop 10から外れただけなので、「セキュアコーディング規約」や「開発時のセキュアコーディングレビュー」などから削除することは、OWASP Top 10でも"Retired, but not forgotten"とあるとおり、避けたほうが良いと思われます。

【要件11.3】

Webアプリケーションペネトレーションテストの診断項目に、今回追加された2つの脆弱性「XML外部実体参照（XXE）」「安全でないデシリアライゼーション」が含まれているか確認し、含まれていない場合は診断業者に追加された2つの脆弱性を含めるように依頼するなどの対処をする必要があります。 2017/11/14初版作成 2017/11/21 OWASP Top 10プロジェクトからの正式版リリースに伴い、RC2版からの変更内容を1)および2)に反映

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当チーフコンサルタント
今川大輔（CISSP）