APIセキュリティを紐解く5つの「知ろう」ポイント

　近年、アプリケーションプログラムインターフェース（API）の普及が急速に進んでいます。Web、モバイル、IoTデバイスなど、さまざまなプラットフォームでAPIは不可欠な役割を果たしています。しかし、その便益と同時に、APIは攻撃者にとっても魅力的な標的となっています。

　本記事では、事例から現在の状況を紐解きつつAPIセキュリティのポイントをわかりやすく解説します。

▼ 目次
１．APIを知ろう
２．APIを利用した攻撃および攻撃傾向を知ろう
３．被害事例を知ろう
４．APIセキュリティとWAFの違いを知ろう
５．APIセキュリティのポイントを知ろう

１．APIを知ろう　― なぜ今、APIの利用が急速に進んだのか

　昨今、多くの企業がアプリケーション（以降はアプリと記載) をより活用されるべく、公開APIの開発に取り組んでいます。

　API(Application Programming Interface)とは、あらかじめ用意された機能を利用するためのインターフェースを指します。APIにより企業間のコラボレーションが実現し、アプリ開発者はアプリのコアになる機能の開発に焦点を当てることができるようになりました。
例えば、ある企業が作成しているアプリに、目的地までの道順を表示する機能をつけようとした場合、従来は地図機能などを個別に実装する必要がありました。しかし、現在はGoogle が開発しているGoogle Maps APIと連携して簡単に実装することができます。これにより、アプリ開発者は地図機能実装以外の開発に注力できるようになります。
　こうした利便性から、APIの利用は急速に進んでいき、2018年10 月にAkamai が実施した調査では、APIのリクエスト通信がWebトラフィックの 83 パーセントも占めているという報告もあります。

　前述のように、公開APIが開発されて普及しているものの、そのセキュリティ対策である “APIセキュリティ” を行っている企業は現状多くはありません。
一方で、セキュリティメーカーは自社製品にAPIセキュリティ関連の機能を搭載、専用ソリューションのリリースを行うなど、その必要性を強く訴求しています。

　そういった中で、自社でAPI公開を行う企業は、今後 “APIセキュリティ” を意識しなければ、開発したアプリもユーザーにとって扱いづらいものになってくるかもしれません。

２．APIを利用した攻撃および攻撃傾向を知ろう

　Webアプリセキュリティ分野の研究等を行う国際的な非営利団体のOWASPが、2019年、2023年と「OWASP API Security Top 10」を発表し、API攻撃手法をまとめています。これにより、攻撃傾向の変化を読み取ることができます。

図1. OWASP API Security top 10の概要（OWASP発表に基づきCTCが作成）
https://owasp.org/API-Security/

　まずは上位の項目を確認してみましょう。2019年版と2023年版を比較すると、1位2位は変わらず認証や認可に関する不備になっています。本来は権限を持たないユーザーにリソースへのアクセスが許可されてしまうことで情報漏洩に繋がります。

　次に3位を見てみましょう。2023年版の「オブジェクトプロパティレベルの認可の不備」は、2019年版にある「過度なデータ公開」と「一括割り当て」が統合された項目になります。
過度なデータ公開は、APIレスポンスに必要以上の情報が含まれている事を意味します。一見、1位の「オブジェクトレベルの認可不備」との差が分かり難いですが、1位がオブジェクト自体の認可を指し、こちらはオブジェクト内のプロパティ情報の認可を指します。　オブジェクトへの対策がされてもプロパティへの対策がされているとは限りません。APIではすべてのオブジェクトプロパティを返す傾向があるとし、注意が促されています。

　また、GraphQL（A PI用クエリ言語)などはどのプロパティを返すかの指定をするためにリクエストに手を加える必要がある場合も想定されます。そういった作業を簡易にするための機能を利用して一括で自動割り当てを行うことがあります。この機能の脆弱性を利用して、通常は制限すべきデータ項目の変更が行えてしまう可能性があります。

　4位の「制限のないリソース消費」に関しても2019年版と2023年版は同様の内容です。リソース消費を制限しないAPIを利用されてしまい、DoSが引き起こされるの可能性があります。

　2023年版で出てきた新項目をピックアップしてみましょう。10位の「APIの安全でない使用」は、弱いセキュリティのサードパーティAPIと連携を行うことを指します。開発者はサードパーティAPIから受信するデータを疑わない傾向があります。加えて、急速に普及したAPIはセキュリティの考慮よりも開発速度や利便性が重視されることもあります。特に、よく知るサードパーティ APIの場合は信頼しすぎて適切な検証を怠るケースが多分にあり、攻撃者に侵害されたサードパーティAPI 経由で攻撃を受ける可能性が発生します。機能連携による開発が当たり前になってきた今、特に注意が必要です。

３．被害事例を知ろう

　実際の攻撃被害例を見てみましょう。APIを利用されて情報漏洩が起こってしまった場合、APIの機能や性質上、漏洩する情報の件数が多くなるケースが散見されます。

　2022年7月以降：Twitter（現X)
　一部メディアで、ハッカーが集まる掲示板であるハッカーフォーラムにて“2億件を超えるTwitterアカウントのデータを公開した”と主張する投稿があったと報じられました。2021年6月～2022年1月の間、Twitterが提供していたAPIに脆弱性が含まれており、これを利用して情報取得したとする投稿が複数回あったとのことです。
　Twitterアプリには「見つけやすさと連絡先」という設定項目があり、この有効化により電話番号やメールアドレスを使って他のアカウントから利用者を検索できるようになります。しかし、バグによりこの設定に関わらず利用者が特定できてしまい、攻撃者に利用された疑いがありました。
　なお、報道されている情報漏洩したアカウント数は、Twitterの認識と差があるとしているものの、APIの脆弱性が悪用されたという点は事実です。

　参考：
　・一部のアカウントや個人情報に影響を及ぼす問題について（2022年8月5日）

　・Update about an alleged incident regarding Twitter user data being sold online(January 11, 2023)

　・2018年3月、2023年1月：T-mobile
　　ドイツに本社を置くT-mobileは何度もサイバー攻撃を受けており、APIを利用されたものとしては2018年に200万人以上、2023年に約3,700万人もの情報漏洩が起こっています。
　　具体的な侵害内容を公にはしていませんが、T-mobileのAPIの1つが標的とされ、クライアントの氏名や電話番号、メールアドレス、郵便番号の他、生年月日や口座番号まで漏洩してしまいました。

　　参考：「T-Mobile Informing Impacted Customers about Unauthorized Activity(January 19, 2023)

４．APIセキュリティとWAFの違いを知ろう

　　APIセキュリティは、Web サーバのセキュリティ対策になるWAFの防御範囲と重なる部分があります。Web APIはHTTP通信を用いるため、WAFの防御範囲に入ります。
　では、どういった違いがあるのでしょうか。

　WAFはWeb アプリの脆弱性を防ぎますが、この脆弱性にはある程度のパターンがあり、シグネチャ（パターン)マッチングによって防御を行います。あるWAF製品ではシグネチャ数が数千程度とされていますが、比較的成熟したセキュリティ分野であるWAFのシグネチャ数は大きく増減されにくいものです。
　一方、Web APIは取得情報や処理内容によってパラメータを変更して通信を行いますが、パラメータやリクエストボディ部分の設計はAPI公開をしている開発側の設計に依存してしまいます。そのため、APIごとに脆弱性のパターンが変わってしまうという状況が発生します。WAFのようなシグネチャマッチングでは、日々新しく開発・公開されているAPIにメーカー側の対応が追い付かずにシグネチャの作成が後手になることは想像に難くありません。そういった理由から、API特有の攻撃に対応するためには、ふるまいを学習、分析した検知が肝になると言えます。

図2. 製品ごとの防御範囲

５．APIセキュリティのポイントを知ろう

　APIセキュリティを検討するうえでのポイントについて考えます。
　
　ポイントは以下の3つです。1つずつ掘り下げてみましょう。

（1）APIの検出
（2）APIの監査・評価
（3）APIの保護

（1）APIの検出

　まずは、未把握のAPIを無くすことが重要です。
他分野のセキュリティ対策同様に、認識していないAPIが存在していないか環境下のAPIを把握して、リスクを認識する必要があります。例えば、開発のテスト過程で連携したもののそのまま放置されているサードパーティAPIや、使われなくなってしまったAPIなどがある場合、攻撃者に利用される可能性があります。
APIセキュリティの専用製品を導入した場合は、そういったシャドーAPIを検出する機能が活用できます。

（2）APIの監査・評価

　次に、把握したAPIに対して、継続的なリスク監査・評価を行うことが大切です。
　情報漏洩やコンプライアンス違反に繋がるような機密データを扱うAPIや、そのAPIと通信するエンドポイントを把握して、APIコーディングエラーや攻撃リスクが考慮されていない箇所の修正を行っていく必要があります。
　
　APIセキュリティ専用製品では、自身が検出した公開APIに対してリスク評価を行います。
自社開発のAPIのみならず、サードパーティAPIも含めて網羅的かつ継続的に評価を行える点が専用製品の強みといえます。

　一方、自社開発APIのリスク対応という観点においては、開発工程にセキュリティ対策のプロセスを組み込み、成果物自体の安全性を高めていくことも重要です。
いわゆるDevSecOpsやシフトレフトと呼ばれるアプローチで、一例としてIAST(Interactive Application Security Testing)ツールを活用した脆弱性検出、対応が挙げられます。

　IASTはAPIに特化したものではありませんが、従来のテスト手法と比べて高精度なリスク評価が可能で、リアルタイムでの検査やCI/CDツールとの連携による自動化によって作業の手戻りや待ち時間を減らすことで、スピードと安全性を両立させた開発を実現します。IASTの詳細については別の記事で掲載予定です。

（3）APIの保護

　最後のポイントは、APIの保護を行うことです。
　前述のWAFとの違いでも触れましたが、他セキュリティ製品でも守られる範囲はあります。インジェクションやサーバサイドリクエストフォージェリ(SSRF)等の攻撃に対しては既に対策が十分であるかもしれません。しかし、API特有の攻撃を防御するためにはAPIセキュリティ専用製品などで対策の検討が必要になります。

　APIセキュリティ専用製品での対策においては、“ふるまいを学習、分析した検知”が行われます。
　例えば、ある製品では、過度なデータ公開を検知するために一定期間の通信を観測してベースラインを定め、ベースラインを超過してデータ公開を行っている動きを検知します。専用製品では、そのようなアノマリ検知（異常検知 )や機械学習での検知が行われます。
　また、ある製品ではAPIのアクティビティの情報を蓄積してタイムライン化された情報を確認することができます。セキュリティ製品において誤検知や過検知は完全に無くせるものではありませんが、判断する際に調査のしやすさは大切な要素になります。製品を活用する場合は運用も含めて考えていく必要があるでしょう。