OWASP のウェブアプリケーションの脅威トップ10

概要

API エコシステムは、外部クライアントと内部クライアントの両方からさまざまな攻撃を受けます。API の提供と使用は、サービスプロバイダに大きなチャンスをもたらしますが、同時にセキュリティリスクも引き起こします。デベロッパーは、API を作成して使用するときに、このような課題を認識して、それらに対処する必要があります。

OWASP は、信頼できるアプリケーションと API の開発、購入、メンテナンスを支援する組織専用のオープンコミュニティです。OWASP API Security プロジェクトを通じて、OWASP はウェブアプリケーションと REST API にとって最も重要なセキュリティリスクを公開し、それらのリスクに対処するための推奨事項を提供しています。

Apigee を使用すると、バックエンドシステムでリクエストが処理される前に、API プロキシレイヤがクライアントからの不正な API リクエストを検出、ブロック、報告できるため、リスクを軽減しサービスを保護できます。不正なリクエストには、HTTP アプリケーションレベルのプロトコルを構成する次のコンポーネントが含まれることがあります。

URL
ヘッダー
パス
ペイロード

不正な API リクエストは、外部デベロッパー、内部デベロッパー、または悪意のあるボットによって開発された既知または未知のクライアントから送られてくる場合があります。この種のリクエストが OWASP の脅威の大部分を占めていますが、リスクを軽減することが可能な、データマスキング、ロギング、管理などの基礎となる API プロキシレイヤの追加コンポーネントが用意されています。

Apigee のインテリジェントな API 管理プラットフォームを使用すると、API の設計および API とバックエンドシステムとの接続に対する消費に焦点を当てたアプローチを採用することになり、重要な OWASP API セキュリティの脆弱性にシームレスに対処できます。Apigee が重要な REST OWASP の脅威に対して推奨しているポリシーと構成のリストを以下に示します。

2017 OWASP Top 10 向けの Apigee ソリューション

ウェブアプリケーションの構築と保護に関しては、セキュリティ上の懸念が多くあります。OWASP は、ウェブアプリケーションに関する Top 10 OWASP Security Threats 2017 のリストを公開しました。ウェブアプリケーションは多くの部分から構成されていますが、最新のウェブアプリのほとんどが REST API に大きく依存しています。Apigee は、ウェブアプリケーションのすべてのセキュリティニーズを処理するようには設計されていませんが、REST API の保護において極めて重要な役割を果たすことができます。OWASP の主要なセキュリティの脅威と、Apigee を使用してこれらの脅威に対処する方法の説明を以下に示します。

A1:2017 - インジェクション

意図されていないコマンドの実行や不正なデータアクセスを引き起こす可能性がある SQL、NoSQL、LDAP、JavaScript などの信頼できないデータインジェクションから保護するために、Apigee は複数の入力検証ポリシーを提供することで、さらなる処理を許可する前に、クライアントから提供された値が期待値と一致するかどうかを検証します。受信 API リクエスト用のサーバーとして機能する Apigee Edge は、ペイロード構造が許容範囲内に収まっていることを確認します。これは制限チェックとも呼ばれます。入力検証ルーチンで入力を変換して危険な文字シーケンスを削除し、安全な値に置き換えるように、API プロキシを構成できます。

Apigee プラットフォームで入力を検証するためのアプローチがいくつか用意されています。

JSONThreatProtection は、JSON ペイロードの脅威をチェックします。
XMLThreatProtection は、XML ペイロードの脅威をチェックします。
パラメータ検証は、JavaScript を使用して実行できます。
ヘッダー検証は、JavaScript を使用して実行できます。
SQLCodeInjection は、RegularExpressionProtection ポリシーを使用して処理できます。

コンテンツタイプを検証します。

リクエスト - プロキシフローで条件ロジックを使用して Content-Type をチェックします。AssignMessage ポリシーまたは RaiseFault ポリシーを使用してカスタムエラーメッセージを返します。
レスポンス - プロキシフローで条件ロジックを使用して Content-Type を検証します。AssignMessage ポリシーを使用して Content-Type ヘッダーを設定するか、AssignMessage または RaiseFault ポリシーを使用してカスタムエラーメッセージを返します。

A2:2017 - 不完全な認証とセッション管理

攻撃者は、アプリケーションの実装欠陥を利用して、パスワード、セッショントークン、キーにアクセスし、他のユーザーになりすますことができます。これは、プロダクトの問題ではなく、実装の問題です。Apigee は、VerifyApiKey、OAuth、JSON Web Token（JWT）ポリシーを提供しており、これらはこの脆弱性に対する保護に役立ちます。

API キー検証

API キー検証は、API 用に構成可能なアプリベースのセキュリティの中で最も簡単な方法です。クライアントアプリはリクエストと一緒に API キーを提供し、Apigee Edge は API プロキシに関連したポリシーにより、リクエストされたリソースに対して API キーが承認状態かどうかをチェックします。

Apigee は、API キーの生成と検証のサポートを提供します。1 つ以上の API プロダクトにリンクされたデベロッパーアプリが作成および承認されると、API キーとシークレットを生成します。

「API キー」という用語は、別のことを意味する場合があります。Apigee では、アプリとプロダクトの関係が構築されると、クライアント ID とクライアントシークレットが生成されます。ID とシークレットの両方を API キーと呼ぶ場合もあれば、クライアント ID のみを API キーと呼ぶ場合もあります。Edge UI には、「コンシューマキー」と「コンシューマシークレット」と表示されます。

VerifyAPIKey ポリシーでは、クライアント ID、つまり、「コンシューマキー」のみが検証されます。デベロッパーは、アプリを Apigee に登録して API プロダクトに関連付けると、コンシューマキーを受け取ります。そして、アプリが API プロダクトにバンドルされた API プロキシに対して行う呼び出しにコンシューマキーを含めます。

Apigee は、外部ソースから既存の API キーをインポートする機能もサポートしています。

OAuth 権限付与タイプでは、クライアント ID とシークレットの両方が使用されます。

OAuth 2.0

OAuth 2.0 認可フレームワークは、サードパーティのアプリケーションによる HTTP サービスへの限定的なアクセスを可能にします。サードパーティアプリケーションがアクセス権を取得する際に、リソース所有者と HTTP サービスの間の承認のためのやり取りをリソース所有者に代わってオーケストレートして行う場合と、サードパーティアプリケーションが自らの権限においてアクセス権を取得できるようにする場合があります。

Apigee の OAuth 2.0 ポリシーを使用すれば、4 つの OAuth 2.0 権限付与タイプを実装してカスタマイズできます。OAuthv2 ポリシーを使用して、OAuth アクセストークンの適用を実施できます。コンシューマは、登録されて、API へのアクセス権が付与されるようにアプリが承認される必要があります。その際に、API クライアント ID とクライアントシークレットを受け取ります。コンシューマは、認証対象の OAuth 権限付与のいずれかを通過する必要があります。これにより、専用のアクセストークンが付与されます。このトークンを使用して、API へのアクセスを制御できます。

JWT

JSON Web Token（JWT）は一般的に、接続されているアプリケーション間でクレームやアサーションを共有するために使用されます。Apigee は、次の 3 つのポリシーを使用して JWT サポートを提供します。

GenerateJWT トークン（HS256 署名と RS256 署名をサポート）
ValidateJWT トークン
検証なしの DecodeJWT トークン

A3:2017 - 機密データの漏洩

攻撃者は、クレジットカード情報、社会保障番号、ログイン資格情報、個人を特定できる情報（PII）、納税者番号などの機密データを標的にして、個人情報の盗難、金銭の盗難、不正行為、その他の罪を犯します。ウェブアプリケーションは、機密データを保護するために、保存時と転送時の両方での暗号化およびその他の手法を実装する必要があります。

TLS（Transport Layer Security、前身は SSL）は、ウェブサーバーとウェブクライアント（ブラウザやアプリなど）の間で、暗号化されたリンクを確立するための標準的なセキュリティテクノロジーです。Apigee は、一方向 TLS と双方向 TLS の両方をサポートしています。

上り方向 TLS（サーバーとして機能する API に接続するクライアント）は、仮想ホスト構成の使用を通してサポートされます。仮想ホストは、一方向 TLS 用または双方向 TLS 用に構成できます。

下り方向 TLS（バックエンドサービスに接続するクライアントとしての Apigee）は、ターゲットサーバー構成の使用を通してサポートされます。ターゲットサーバーは、一方向 TLS 用または双方向 TLS 用に構成できます。

Apigee は、さまざまな TLS 構成オプションをサポートしています。

双方向 TLS を適用すれば、クライアントが Apigee にオンボードされた証明書を使用していることが保証されます。OWASP は、TLS ベストプラクティスも提供しています。

Apigee Hybrid では、ホストエイリアス経由の入り口で TLS を使用できます。これは、仮想ホストと同様のコンセプトです。

機密データを保護するためのガイドラインを以下に示します。

プロトコルレベルで保護する一方向 TLS と双方向 TLS をサポートするプラットフォームを使用します。
AssignMessage ポリシーや JavaScript ポリシーなどのポリシーを使用して、クライアントに返される前に機密データを削除します。
標準の OAuth 手法を使用し、HMAC、ハッシュ、ステート、ノンス、PKCE、またはその他の手法を追加して、各リクエストの認証レベルを高めることを検討します。
データマスキング設定を使用して、Edge Trace ツールにおいて機密データをマスクします。
キャッシュに機密データを格納する場合には注意して行います（またはキャッシュに格納される機密データは暗号化します）。Edge では、Key-Value マップに保存される機密データを暗号化できます。

A4:2017 - XML 外部エンティティ

XML を処理するシステムまたはアプリケーションは、XML 内の「外部エンティティ参照」、つまり、XML 処理中に実際のデータに置き換えられるファイルまたはデータへの参照を処理する必要があります。アプリケーションまたは XML プロセッサが古いか実装が不十分な場合は、攻撃者がデータをハッキングして、それを利用して情報を盗んだり、サービス拒否攻撃などのシステムに対するさまざまな攻撃を仕掛けたりすることができます。

Apigee の ExtractVariables ポリシーを使用すれば、リクエストまたはレスポンスからコンテンツを抽出して、そのコンテンツを変数に割り当てることができます。ヘッダー、URI パス、JSON ペイロード、XML ペイロード、フォームパラメータ、クエリパラメータなど、メッセージの任意の部分を抽出できます。このポリシーは、メッセージコンテンツにテキストパターンを適用し、一致するものを見つけると、変数を設定し、指定されたメッセージコンテンツを代入するという仕組みになっています。

Apigee には、プラットフォームの一部として、XPath を使用してデータを抽出する XML パーサーが組み込まれています。また、悪意のある XML ペイロードから保護するための XMLThreatProtection ポリシーもあります。

A5:2017 - 不完全なアクセス制御

ユーザーがログインしてシステムにアクセスしたら、そのユーザーが許可されていることだけを表示して実行できるように、適切な承認制御を実施する必要があります。強力なアクセス制御がないと、攻撃者は無許可で機密性の高いデータを表示したり、データやシステムの動作を悪意を持って操作したりできます。

Apigee は、悪意のある人物が不正な変更を行ったりシステムにアクセスしたりするのを防ぐために、アクセス制御を実装する階層化アプローチをサポートしています。

Edge UI 用のアクセス制御

会社の ID プロバイダを使用したシングルサインオンを構成します。
ロールベースのアクセス制御（RBAC）を構成して、ユーザーが必要な機能と構成にのみアクセスできるようにします。
Teams 機能は、プロキシ、プロダクト、アプリへのアクセスを制限する追加機能を提供します。
データマスキングを構成して、ユーザーから機密データを隠します。
暗号化された Key-Value マップを作成し、機密 Key-Value ペアを保存します。このペアは、Edge UI および管理 API 呼び出しではマスクされて表示されます。

Apigee デベロッパーポータル用のアクセス制御

会社の ID プロバイダを使用したシングルサインオンを構成します。
ロールベースのアクセス制御（RBAC）を構成して、ユーザーが Drupal ベースのデベロッパーポータルで必要な機能と構成にのみアクセスできるようにします。
ユーザーロールに応じて特定の API プロダクトを表示するようにデベロッパーポータルを構成します。
ユーザーロールに基づいてコンテンツを表示または非表示にするようにポータルを構成します。

Apigee ランタイム API アクセス用のアクセス制御

API へのアクセスは、API キー、OAuth トークン、OAuth スコープ、証明書、その他の手法を通して実施できます。
API プロバイダは、API プロダクトを定義することにより、使用可能なリソースを構成します。アクセス権は、UI で手動で、管理 API を介して、またはデベロッパーポータルを介して付与されます。デベロッパーのアプリに API プロダクトへのアクセス権が付与されると、認証プロセスで使用されるクライアント ID とシークレットを受け取ります。
Apigee は、任意の ID プロバイダと統合して OAuth を実行できます。
Apigee は、JWT トークンまたはその他の手法を生成して、ユーザー ID をターゲットサービスに送信できます。ターゲットサービスは、必要に応じて、その ID を使用して、サービスとデータへのアクセスを制限できます。

A6:2017 - セキュリティの構成ミス

多くの管理者とデベロッパーが、使用しているシステムが本質的に安全であると誤って信頼しているために、セキュリティの構成ミスが簡単に見落とされています。セキュリティの構成ミスは、デフォルトの構成を信頼したり、安全でない可能性があるにもかかわらず部分的な構成を行ったり、エラーメッセージに機密情報を含めたり、適切なセキュリティ制御なしでクラウドにデータを保存したり、HTTP ヘッダーを誤って構成したりするなど、さまざまな方法で発生します。Apigee プラットフォームには、再利用可能な共有フローなど、セキュリティ構成を制御、管理、モニタリングできるメカニズムが多数用意されています。

共有フローを使用すれば、API デベロッパーは、ポリシーとリソースを再利用可能なグループにまとめることができます。再利用可能な機能を 1 か所に集約することにより、共有フローは整合性を保証し、開発時間を短縮して、コードをより簡単に管理するのに役立ちます。個々の API プロキシ内に共有フローを含めることも、さらに進んでフローフックに共有フローを配置して、共有フローと同じ環境にデプロイされたすべての API プロキシの共有フローロジックを自動的に実行することもできます。

Apigee プロダクトリリースは、脆弱性のあるライブラリに対する保護を保証します。Apigee は、新しい脆弱性が見つかった場合に、追加のパッチまたはアップデートをリリースする可能性があります。Edge for Public Cloud には自動的にパッチが適用されます。Edge for Private Cloud（オンプレミス）のお客様は、プロダクトパッチをご自身で適用する必要があります。

A7:2017 - クロスサイトスクリプティング（XSS）

クロスサイトスクリプティング（XSS）を使用すれば、攻撃者は、ユーザーのウェブブラウザでスクリプトを実行して、ユーザーセッションを制御したり、ウェブサイトを操作したり、その他の方法でユーザーに悪影響を及ぼしたりすることができます。XSS の問題は必ずしも API に関連するわけではありませんが、Apigee は API の XSS を防ぐために活用できる脅威保護ポリシーを提供しています。RegularExpressionProtection ポリシーまたは JavaScript ポリシーで正規表現を使用して、JavaScript やその他のインジェクション型攻撃のペイロード値とパラメータ値をチェックしてください。

CORS は、すべてのブラウザによって適用される同一オリジンポリシーに対して一般的に実装されるソリューションの 1 つであり、AssignMessage ポリシーを使用して実装できます。

A8:2017 - 安全でない逆シリアル化

攻撃者は、リプレイ、権限昇格、インジェクションなどのさまざまなタイプの攻撃に逆シリアル化の欠陥を利用できます。安全でない逆シリアル化は、リモートコード実行を可能にする場合もあります。

Apigee では、逆シリアル化を推奨していません。ただし、JSONThreatProtection ポリシーと RegularExpressionProtection ポリシーが悪意のある JSON ペイロードに対する保護に役立つ場合があります。JavaScript ポリシーを使用して、ペイロードに悪意のあるコンテンツがないかスキャンすることもできます。キャッシュとその他のポリシーを使用して、リプレイ攻撃から保護できます。インフラストラクチャレベルで、Apigee プラットフォームには、実行中のプロセスを保護するためのガードレールも組み込まれています。

A9:2017 - 機知の脆弱性のあるコンポーネントの使用

フレームワーク、ライブラリ、モジュールはフル実行と CRUD アクセスで動作するため、攻撃者はコンポーネントの脆弱性を利用してシステムを攻撃できます。

Apigee の定期的なプロダクトリリースでは、特に、特定の脆弱性が発見された場合に、コンポーネントの脆弱性に対する保護が保証されます。Apigee Public Cloud は自動的にパッチが適用され、Edge for Private Cloud のお客様にはオンプレミスパッチがインストール可能になった時点で通知が送られます。

A10:2017 - 不十分なロギングとモニタリング

システムでロギング、モニタリング、インシデント管理が適切に実行されていない場合は、攻撃者がデータとソフトウェアに対してより深い攻撃を長期にわたって加えることができます。

Apigee では、ロギング、モニタリング、エラー処理、監査ロギングを実行するいくつかの方法を用意しています。

ロギング

ログメッセージは、MessageLogging ポリシーを使用して、Splunk やその他の syslog エンドポイントに送信できます。
API 分析データは、Analytics API を介して pull し、他のシステムとの間でインポートまたはエクスポートできます。
Edge for Private Cloud では、MessageLogging ポリシーを使用してローカルログファイルに書き込むことができます。実行中のコンポーネントごとのログファイルも利用できます。
JavaScript ポリシーを使用して、ログメッセージを REST ロギングエンドポイントに同期的または非同期的に送信できます。

モニタリング

API Monitoring UI または API を使用して、API とバックエンドを定期的にモニタリングして、アラートをトリガーします。
ヘルスモニタリングを使用して、ターゲットサーバーのバックエンドを定期的にモニタリングします。
Apigee は、Edge for Private Cloud をモニタリングするための推奨事項を提供しています。
また、Apigee は、チームが API プログラムのモニタリングに活用可能なベストプラクティスも提供しています。

エラー処理

Apigee は、API プロキシ用の強力で汎用性の高い障害処理メカニズムを提供しています。Java プログラムが例外をキャッチする方法と同様に、API プロキシは障害をキャッチして、クライアントに適切なレスポンスを返す方法を決定できます。Apigee のカスタム障害処理を使用すれば、エラーが発生したらいつでもメッセージログを記録する機能などを追加できます。

監査ログ

Apigee プラットフォームは、API プロキシ、プロダクト、組織履歴に対する変更を追跡する監査ログを保持します。このログは、UI を介してまたは Management API を介して入手できます。

2013 OWASP 脆弱性のための Apigee ソリューション

OWASP が 2017 年にリストを更新したときに、2013 年のリストに掲載されていた脆弱性の一部が除外されました。それらは現在も有効な脅威です。以降のセクションでは、これらの脅威を Apigee で処理する方法について説明します。

A8:2013 - クロスサイトリクエストフォージェリ（CSRF）

クロスサイトリクエストフォージェリを使用すれば、攻撃者は HTTP を介してユーザーの認証詳細、セッション Cookie、その他のデータを脆弱なウェブアプリケーションに転送し、ウェブアプリケーションにユーザーからの正当なリクエストであると信じ込ませることができます。

ガイドライン:

これは、API プロダクトの問題ではなく、ブラウザの問題です。この脆弱性は、OpenID Connect や OAuth などの手法で対処できます。
HMAC、ステート、ハッシュ、ノンス、または PKCE 手法を使用して、フォージェリ攻撃とリプレイ攻撃を防止することを検討してください。

A10:2013 - 未検証のリダイレクトと転送

ウェブアプリケーションがリダイレクトを実行する場合、そのリダイレクトによってユーザーが信頼できる意図されたウェブサイトに送信されることを検証しないと、攻撃者はユーザーを悪意のある宛先に送信して、フィッシングやマルウェア実行などの攻撃を実施できます。