Web APIセキュリティとは？

Web APIセキュリティとは？

APIのウェブセキュリティとは、アプリ間の連携を狙った悪意ある攻撃や乱用を防ぐための施策や仕組み全般を指します。APIが電子連携の要となっているため、プログラマーにとって極めて重要な存在となりました。その結果、従来はクライアント名とパスワードのみで行われていた基本認証は、多要素認証（MFA）など、さまざまなセキュリティトークンに置き換えられています。

APIは、シンプルさが特徴のウェブサービス構築手法であるREpresentational State Transfer (REST)か、アプリ間でメッセージをやり取りするための規格であるSimple Object Access Protocol (SOAP)のいずれかを用いて作られます。SOAPはHTTPなどを含む複数の低レベルプロトコルに拡張可能です。一方、REST APIはHTTPと伝送層セキュリティ (TLS) を利用し、Webアプリでシンプルなデータ構造や文書を扱うためのテキストベースのデータ交換フォーマットであるJavascript Object Notation (JSON) を使用します。

なぜAPIウェブセキュリティを使うのか？

サイバー攻撃が増加しており、特に乗っ取られた認証情報やAPIを狙った攻撃が問題視されています。APIに対する攻撃として、中間者攻撃、境界攻撃、認証攻撃などが挙げられます。

そのため、大手ウェブセキュリティ企業は、防御策の一環として、多要素認証（MFA）の導入を求めています。MFAは、ログインやその他の取引時に、複数の方法での確認を要求するセキュリティフレームワークです。例えば、AmazonやMicrosoftなどは、2019年8月以降、クラウドプロバイダー、管理者、パートナーに対して、管理アカウントを含むすべてのユーザーにMFAの利用を義務付けています。

APIセキュリティの実施は、クロスサイトスクリプティング (XSS) やSQLインジェクションといった攻撃を防ぐとともに、機密情報の漏えいから守るために重要です。総じて、APIおよびそれに依存するアプリの安全な運用のためには、APIセキュリティが欠かせません。

Wallarmは、OWASP API Security Projectの次の言葉を紹介します: "APIは現代のモバイル、SaaS、ウェブアプリの基盤であり、クライアント向け、パートナー向け、内部アプリに存在します。もちろん、APIは業務ロジックや個人情報などの機密情報にもアクセスするため、攻撃者の標的となりやすいのです。安全なAPIがなければ、迅速な開発は不可能です。"‍

API方式の種類

APIを実装する際、最も一般的な方式はSOAP方式とREST方式です。

1.    SOAP API

SOAPとは、Simple Object Access Protocolの略で、PC間でデータを交換するためのXMLベースの通信規格です。SOAPの標準WS-Security規格は、XML暗号化、XML署名、SAMLトークンを用いて厳格な通信セキュリティチェックを実施します。また、OASISやW3Cの規格にも準拠しています。

SOAPが採用するルールと、封筒形式でペイロードを送信する方式は、追加のオーバーヘッドが必要となり、RESTのような簡易なAPI呼び出しとは異なります。しかし、より厳密なセキュリティと整合性が求められる場合には、SOAPの利用が有利となることがあります。

2.    REST API

RESTとは、Representational State Transferの略で、HTTPを用いてデータを取得し、遠隔のPCシステム上で処理を実行する方式です。SSL検証とHTTPSによる安全な通信が採用されています。

RESTは、APIペイロードの処理にJSONフォーマットを利用することで、データ転送プロセスを簡素化します。また、RESTはステートレスであり、各HTTPリクエストに必要な情報が全て含まれているため、クライアントやサーバが追加の状態を保持する必要がありません。SOAPと異なり、ローカルなウェブフレームワーク毎の解析・処理を必要とせず、標準のHTTPリクエストのみで対応できるため、データの再梱包の手間が省かれます。

SOAP APIとREST APIの比較‍

前述の通り、API方式には主にSOAP APIとREST API（またはRESTful API）の二種類があります。

REST APIはより現代的ですが、SOAP APIは歴史があり広く実装されています。両方式ともHTTPリクエストとレスポンスでデータをやり取りしますが、その構造や使用する言語には大きな違いがあります。どちらも通信中のデータ保護にSSLを利用していますが、その他の特徴には差があります。したがって、SOAPとRESTのセキュリティは、それぞれの実装方法や意味に依存します。

SOAP APIはREST APIより歴史が長いことから、特定のセキュリティ課題に対応するための拡張が施されています。大規模なプロジェクトでSOAPを利用する場合、W3CやOASISの提案、具体的にはXML暗号化、XML署名、SAMLトークンなどの利点を享受できます。

また、SOAPはWebサービス標準のサポートが充実しており、WS-ReliableMessaging仕様による組み込み型の通信エラー処理や、WS-Security仕様によるプロジェクトレベルのセキュリティ保証が提供されます。

一方、REST APIには特定のセキュリティモデルや機能は組み込まれていません。これは、RESTが主にデータの転送と消費に焦点を当て、セキュリティや健全性を伝達プロセスに含めていないためです。そのため、REST方式では、開発者がコーディング、送信、転送の各段階でセキュリティ対策を十分に講じる必要があります。

さらに、WS-ReliableMessagingがSOAP APIに組み込まれているのに対し、REST APIではエラー発生時にデータの再送が必要となります。

もし、金融残高やクレジットカード情報などの機微なデータを扱う場合、API選定においてはSOAPが有利な可能性があります。ただし、APIセキュリティの真価はその実装方法に依存し、安全に設計・実装されたREST APIは、不十分な設計・実装のSOAP APIよりも安全です。

3.    GraphQLのAPIセキュリティ

もう一つのAPI方式はGraphQLで、急速に普及しているオープンソースのAPI標準規格です。GraphQLはフロントエンドの開発者にとって特に魅力的で、固定のAPI仕様やURIパスに縛られることなく、アプリや環境に合わせたリクエストを自由に変更できるためです。この柔軟性や、非破壊型のバージョンアップ、パフォーマンス向上などの利点から、Web APIとしての採用が急速に進んでいます。

GraphQLはRESTの代替ではなく、両方式は今後も共存する見込みですが、確実に業界標準の一つとなっています。実際、GraphQLの普及は従来のREST設計に変革をもたらすほどの影響力があります。特筆すべきは、GraphQLのリクエストはHTTP URI経由でアクセスするデータを明示的に指定しない点で、通常はHTTP POSTのボディ内に問い合わせ言語で記述されたデータを解釈します。 

GraphQL APIでは、すべてのリソースに一つのURI（例：/graphql）を通じてアクセスします。従来のWeb APIアクセス制御システムは、この種のAPIトラフィックには必ずしも適用されない場合が多く、GraphQLのアクセス制御は、APIペイロード内の構造化データに基づいて判断される必要があります。いずれにせよ、APIプロバイダーは各仕様に適した設定を慎重に選定するべきです。

OWASP APIセキュリティトップ10（リスト）

OWASPは最近、APIセキュリティトップ10のリリース候補を発表しました。OWASP APIセキュリティプロジェクトについてさらにご確認いただけます。主な10項目は以下の通りです：

• API1 - オブジェクトレベル認可の破損
• API2 - ユーザー認証の破損
• API3 - 過剰なデータ露出
• API4 - リソース不足とレート制限の不備
• API5 - 関数レベル認可の破損
• API6 - 大量代入
• API7 - セキュリティ設定の不備
• API8 - インジェクション
• API9 - 資産管理の不適切
• API10 - ログ記録と監視の不十分

‍

一般的なAPIセキュリティの脅威

APIはその性質上、膨大な情報、場合によっては機密の顧客情報へのアクセスを可能にします。単にSQLインジェクションやXSSだけが問題ではなく、攻撃者が貴社の顧客データや関連情報全体にアクセスする可能性があるため、十分な注意が必要です。

キャプチャやアプリのフィンガープリントといった一般的な防御手段は、設計上、各利用者からの膨大なAPIリクエストに影響するため、十分な効果を発揮しません。では、どこから対策を始めればよいでしょうか。まず、プログラマーの立場に立って考え、ゼロデイ攻撃などに備え、基本的な攻撃やその兆候を検知・遮断する仕組みを導入することが必要です。

1.    MITM

中間者（MITM）攻撃とは、攻撃者がクライアントとアプリ間の通信に割り込み、盗聴またはどちらか一方になりすますことで、通常のデータ交換が行われているかのように見せかける手法です。

攻撃の目的は、ログイン認証情報、アカウント情報、クレジットカード番号などの個人データを盗み取ることです。標的は、多くの場合、金融アプリ、SaaS企業、オンラインマーケットプレイス、その他サインインが必要なサイトの利用者です。

攻撃で取得されたデータは、詐欺、不正な資金移動、または不正なパスワード変更などに利用される可能性があります。また、APT攻撃の侵入段階で、既存ネットワーク内に足がかりを得るために使われることもあります。

広い意味では、MITM攻撃は、郵便配達員が銀行明細書を開封し、情報を記録した後に封をし直して届けるようなものです。攻撃の成功には、割り込みと復号という二つの段階があります。

割り込み

第一段階では、攻撃者のネットワーク経由でクライアントのトラフィックを捕捉し、目的地に届く前に奪取します。より動的な割り込みを行うため、攻撃者は以下の手法を用いることがあります：

• IPスプーフィング
• ARPスプーフィング
• DNSスプーフィング

復号

割り込みの後、双方向のSSLトラフィックは、クライアントやアプリに気付かれずに復号される必要があります。これを実現するため、HTTPSスプーフィング、SSL BEAST、SSLハイジャッキング、SSLストリッピングなどの手法が用いられます。

2.    APIインジェクション（XSSとSQLi）

インジェクション攻撃とは、脆弱なアプリに悪意あるコードを仕込むことで攻撃を行う手法です。特に危険なのは、クロスサイトスクリプティング (XSS) とSQLインジェクション (SQLi)です。

• XSS

クロスサイトスクリプティング (XSS) は、脆弱なウェブアプリに悪意あるコードを注入する一般的な攻撃手法です。他の攻撃手法（例：SQLインジェクション）と異なり、直接アプリ自体を狙うのではなく、その利用者が被害を受けます。

クロスサイトスクリプティング攻撃に成功すると、オンラインビジネスの信用や利用者との関係に大きな影響を及ぼす恐れがあります。攻撃の深刻度に応じ、利用者データの漏えいや、トロイの木馬の実行、ページ内容の改ざんが生じ、利用者が個人情報を知らずに提供してしまう場合があります。最終的には、セッショントークンの奪取により、攻撃者が正規利用者になりすまし、個人情報を不正に利用するリスクもあります。

クロスサイトスクリプティング攻撃は、保存型（持続型）と反射型の二種類に分けられます。

保存型XSSは、悪意あるコンテンツが脆弱なウェブアプリに直接注入されるため、より危険です。

反射型XSSは、ウェブアプリから悪意あるコンテンツが反射され、利用者側で実行される攻撃です。コンテンツはリンクに埋め込まれ、そのリンクがクリックされた際に一度だけ実行されます。

• SQLi

SQLインジェクション（SQLiとも呼ばれる）は、悪意あるSQLコードを用いて、バックエンドデータベースから表示が許されていない情報に不正にアクセスする攻撃手法です。この情報には、企業の機密情報、利用者データ、または個人の詳細情報などが含まれる可能性があります。

SQLインジェクションの被害は甚大で、利用者データの不正閲覧、テーブル全体の削除、場合によっては攻撃者がデータベースの管理権限を取得するなど、事業に大きな打撃を与える恐れがあります。また、電話番号、住所、クレジットカード情報などの個人情報が漏れることで、利用者の信頼損失にも繋がります。なお、この攻撃手法はあらゆるSQLデータベースに対して行われますが、特にウェブサイトが標的となることが多いです。

3.    DDoS

サービス拒否（DoS）攻撃では、攻撃者が大量のメッセージを送信し、サーバやネットワークに過剰な負荷をかけることで、REST APIを機能しなくする可能性があります。最近では、APIが公開されていると、第三者による攻撃リスクも高まります。

こうしたAPIに対するDoS攻撃が増加する中、企業はあらかじめ対策を講じる必要があります。たとえAPIキー（またはアクセス・トークン）を用いた認証があっても、通常のアプリリクエストで再取得可能な場合があり、既存のトークンの無効化は恒久的な解決策とはなりません。さらに、攻撃が特定のIPアドレスに紐付けられていたとしても、攻撃者は容易に別のIPを取得できるため、そのIPのブロックも長続きしません。

そのため、多くのアクセス制御対策が必要です。機微でないデータの場合、APIキーの使用だけで十分なこともありますが、DoS攻撃をより確実に防ぐためには、HTTPSの利用や、OAuth、共通（双方向）TLS検証、SAMLトークンなどの強固な認証要素を併用することが重要です。

また、異常な量のAPIリクエストによってDDoS攻撃やその他の乱用が生じるリスクを防ぐため、各APIに一定期間内のリクエスト上限（スパイクキャプチャとも呼ばれる）を設定してください。上限を超えた場合、該当APIキーからのアクセスを一定期間遮断し、HTTPエラーコード429（リクエスト過多）を返すように設定することが推奨されます。

新しいREST APIの開発を始める際は、さまざまなセキュリティ機能を備えたウェブプロフェッショナルのサポートを検討してください。

APIセキュリティ手法

これまでご紹介した攻撃からAPIを守るためには、以下の対策が有効です：

• 認証

利用者の識別を行います。REST APIでは、基本認証はTLSプロトコルを利用して実現できますが、OAuth 2やOpenID Connectの方が安全な選択肢です。詳細は「REST APIを安全に守る方法」をご参照ください。

• 認可

認証された利用者がアクセスできるリソースを決定します。APIは、利用者が本来の役割外のAPIリソースや操作にアクセスできないよう設計・テストされるべきです。例えば、読み取り専用のAPI利用者が管理者用機能のエンドポイントにアクセスすることは避けるべきです。

さらに、想定されるパターンと一致するかどうかを検証するために、API呼び出しの署名チェックや、ペイロードの解析と検証を行うといった追加対策も有効です。各API呼び出しごとにAPIトークンを付与することで、リクエストの追跡が可能となり、エンドポイントへの攻撃を防ぐ一助となります。

最後に、Web APIを含むすべてのウェブページにTLS/SSLを導入し、送受信されるデータを暗号化・認証することが基本です。これにより、MITM攻撃による通信傍受のリスクを効果的に軽減できます。