APIビジネスロジックの脆弱性
APIビジネスロジックの脆弱性とは、APIの設計および実装における論理的欠陥であり、APIの想定された、計画された、通常の使用方法や動作からの逸脱を引き起こします。これらは不十分な設計および開発手法の例です。
どのように発生するのか？ それらを予防・発見できるのか、その方法は？ 実際に悪用された事例はあるのか？ OWASP APIセキュリティプロジェクトはこれらをカバーしているのか？
APIビジネスロジックの脆弱性に関するこれらの疑問やその他の質問への答えを知るために、読み進めてください。
APIビジネスロジック脆弱性の詳細
ビジネスロジック脆弱性とは、誤ったロジック配置によって引き起こされる予期せぬサイバーセキュリティ上の結果を指す包括的な用語です。ロジック自体は妥当に見えますが、意図しない結果を招きます。こうした予期せぬ状況や状態において、APIは不規則に、時には不安定に動作し、悪用や乱用される可能性があります。
これらの現象はビジネス文脈に限定されないため、技術的に正確な呼称は「ロジック脆弱性」となります。ただし本稿では一般的な名称である「ビジネスロジック脆弱性」を用います。
APIロジックとはAPIの動作原理、すなわちAPIの挙動と利用を規定するルールを指します。ここで言うルールとは「pならばq」といったコードで実装された論理構造を意味します。このルールセットはAPIごとに固有のものです。一例として、「顧客が3点購入した場合、20%割引を適用する」といったルールが挙げられます。
ロジック脆弱性の発見が困難な大きな理由の一つは、この独自性にあります。この種の脆弱性を発見するには、APIとその特異性・固有性を深く理解する必要があり、一般的なセキュリティリスクのパターンには容易には当てはまりません。
もう一つの大きな理由は、APIのビジネスロジック脆弱性が典型的な技術的脆弱性とは異なる点です。インジェクションなどの技術的なAPI脆弱性を検索する場合、発見は比較的容易です。これはセキュリティやコーディングのベストプラクティスに対する明らかな見落としであり、何を探すべきか、どう見つけるかが明確だからです。
一方、ビジネスロジックの脆弱性は「私を見つけて！」と叫んでいるわけではありません。APIの動作に不可欠な部分ではありますが、望ましくない不可欠な部分なのです。その「望ましくない」点を見抜くことが肝心です。
なお「ビジネスロジック」という用語は、人によって定義が異なる点に留意すべきです。ビジネスロジックとアプリケーションロジック、あるいは当ケースではAPIロジックを区別する立場もあります。
ビジネスロジックとは、組織がビジネス目標を達成するための指針となるルールを定義するものです。例えば、価格設定、割引、顧客の権限・権利・制限などはビジネスロジックによって規定されます。
APIロジックは、これらのルールをソフトウェアの文脈で実装する必要があります。ただし、ビジネスロジックとの違いは、APIロジックのあらゆる側面がビジネス目標に関わるわけではなく、ビジネスそのものに関係しない場合もある点です。
例えば、ユーザーが自身のアカウントへのアクセスを要求した際に、4桁のOTPコードをユーザーのモバイル端末に送信する処理はビジネスロジックではありません。これは（公開APIでない限り）APIの動作原理であり、ビジネス目的で開発されたか否かに関係なく適用されるものです。
逆に、購入した特定数の商品に割引コードを適用する処理は、ビジネスロジックの典型例です。
ただし、ここではその区別を行いません。理由は以下の通りです：
- 実際には、APIとビジネスロジックを区別することはしばしば困難であり、厳密な概念上の区別には関心がないためです。
- 予期しないセキュリティ結果をもたらす異なるロジック上の欠陥を同一カテゴリに属するものとして扱うことで、ロジック関連のAPI脆弱性に関する議論が簡素化され、業界ではこの議論方法が主流となっているためです。
APIビジネスロジック脆弱性の例
- クライアントサイド制御への過度な信頼
この場合、開発者はユーザーがAPI、あるいはAPIに依存するWebアプリと、事前定義されたインターフェースを通じてのみやり取りすると想定します。その結果、クライアントサイドのセキュリティ対策のみを実装することになり、これは全く不十分です。
攻撃者はプロキシを使用してAPI通信を傍受し、例えば価格パラメータを変更することで、本来の価格よりはるかに安い価格で商品を購入することが可能です。 - フィルタリングされていない非標準入力値
APIが負の数値や極端に長い文字列値など、非標準的な値の送信をユーザーに許可している場合、ビジネスロジックの脆弱性が生じます。攻撃者はこの弱点を利用して、例えば製品価格を負の数値に変更することが可能です。
このシナリオにおいても、問題は「ユーザーが予期しない値を送信しようとはしない」という根拠のない信頼にあります。 - ワークフロー検証の不備
開発者が、ユーザーが常に特定のリクエスト順序に従うと仮定し、正しい順序を検証しない場合を考えてみましょう。このようなシナリオでは、ハッカーはAPIリクエストの順序を変更し、POSTやGETメソッドを操作することで、商品代金を支払わずにチェックアウトプロセスを完了させることが可能です。
これら3つの事例に共通するのは、APIに関するユーザー行動への前提条件です。明らかな教訓は：いかなる理由があろうとも、ユーザーについて決して何も想定するな、ということです。何があろうと、どこにいようと、誰であろうと、誰と一緒であろうと、どこへ向かおうと、どこにいたことがあろうと、どんな理由があろうとも。
APIビジネスロジックインシデント
USPSデータ漏洩
このセキュリティインシデントは2018年11月に公表されました。米国郵便公社（USPS）のAPIが、欠陥のあるビジネスロジックと破損した認証（API5:2023 機能レベルの認証破損）により、約6000万人のユーザー情報を漏洩させていたことが明らかになりました。破損した認証について詳しく知りたい場合は、最近のインタビュー記事をご覧ください。そこでは、注意すべき主要な脆弱性の一つとしてこの問題を取り上げています。
ここでAPIの話に戻ります。このAPIは企業、広告主、大量郵便送信者が荷物や郵便キャンペーンデータをほぼリアルタイムで追跡することを可能にしていました。問題は、一般ユーザーでもこのデータを見られるだけでなく、さらに他の一般ユーザーのメールアドレス、住所、電話番号などの情報を、システムに問い合わせることで入手できてしまう点でした。しかも、高度な技術やハッキングスキル、ツールがなくてもそれが可能だったのです。
その他のセキュリティ上の問題を別として、これはビジネスロジックの脆弱性の例です。USPSは、通常のユーザーが自身のアカウントとデータのみにアクセスすると想定し、他のユーザーのデータへの不正アクセスを防ぐための対策を何も講じていなかったためです。
Venmoデータ漏えい問題
このデータ漏洩事例は典型的なセキュリティインシデントではありません。むしろ、人気決済アプリ「Venmo」の危険なデフォルト動作と言えます。
2016年から2019年にかけて、複数のセキュリティ研究者がVenmoのAPIに伴うプライバシーリスクを警告していました。このAPIでは、GETリクエストを送信した誰でも、取引を行ったユーザーに関係なく、直近20件の取引情報を閲覧可能でした。さらに、この情報を閲覧するのにVenmoアカウントすら必要ありませんでした。
つまり、GUIの背後にある仕組みを知っている者なら文字通り誰でもAPIにアクセスできたのです。このケースでは、これは単なる見落としではありませんでした。Venmoは、データスクレイピングや悪意のある目的で利用されることはないと想定し、意図的にAPIを公開していたのです。
1分間に2回のリクエストが可能であるため、ある研究者はたった1日で11万5千件の取引情報を照会・ダウンロードできました。
このデータを活用すれば、例えば異なるユーザーの支払い習慣や日常行動を調査でき——時間の経過に伴う行動を追跡し、最も頻繁に交流する相手を特定し、最も購入頻度の高い商品などを把握し、同様の分析が可能——そしてこの知見をソーシャルエンジニアリング攻撃に悪用できます。
ソーシャルエンジニアリングの脅威がなくても、生涯一度も会ったことのない第三者の詮索好きな目に、こうした情報が晒されている事実自体が極めて不快でしょう。
ビジネスロジックの脆弱性とOWASP APIセキュリティトップ10
OWASP APIセキュリティトップ10（最も脅威となるAPIセキュリティリスクの権威あるリスト）は、ビジネスロジックの脆弱性をカバーしているか？
OWASP APIセキュリティトップ10は、ビジネスロジックやロジック上の欠陥について明示的に言及していません。これらが言語的・概念的に最も近いのはAPI6:2023「機密性の高いビジネスフローへの無制限アクセス」です。このことから、API6:2023がこのセキュリティ脅威について（部分的にではありますが）論じている唯一のOWASP APIセキュリティカテゴリーであると結論づけられるかもしれません。
確かに、API6:2023が言及する機密性の高いビジネスフローは、ビジネスロジックの欠陥です。それらは：
- 容易に悪用される
- 一般的だが検出が容易ではない
- 自動化されたサイバー攻撃の影響を受けやすい
- ハッカーがビジネスを深く理解している必要がある
この脆弱性の例として、限定生産で人気が高いスニーカーの無制限購入が挙げられます。
あるオンライン再販業者のプラットフォームが、利用可能な全数量を一度に購入する者はいないと想定していると仮定しましょう。その結果、この種の購入を防ぐ制限を一切設けていない場合、悪意のある行為者がこの論理的欠陥を悪用できます。Apple PayのシャドーAPI悪用においてスニーカー転売グループが行った行為は、ほぼこれに相当します。
この論理的欠陥は典型的なビジネスロジックの脆弱性です。技術的な問題の悪用なしに悪用される可能性があります。
ただし、機密性の高いビジネスフローへの無制限アクセスは、OWASP Top 10 APIロジック関連のセキュリティリスクの唯一のものではありません。特定のケースでは、認証の問題もビジネスロジックの脆弱性と見なされる場合があります。
例えば、APIトラフィックを傍受して認証制御を迂回し、リクエストを改ざんし、一般ユーザーではなく管理者ロールを自身に割り当て、管理者権限を利用してAPIとそれを依存するアプリケーションの両方を悪用できる場合、ビジネスロジック脆弱性を発見・悪用したことになります。
これは認証の欠如や脆弱な認証制御に起因するものではないため、ビジネスロジックの問題です。セキュリティ問題の原因は技術的な問題ではなく、欠陥のあるロジック、すなわち「ユーザーがGUIを超えてアクセス制御を迂回しようとはしない」という前提にあります。
そのため、ロジック脆弱性は自動スキャナーによる検出が困難であり、一般的に見つけにくいものです。ここでは、不足しているセキュリティ対策や脆弱な制御を探すのではなく、ユーザーがAPIとどのようにやり取りするかを想定した基盤となるロジックを探します。そしてそれを理解するには、APIの内部動作を理解しなければなりません。
結論として、OWASP APIセキュリティトップ10はビジネスロジックの脆弱性に関連しますが、それは部分的なものに過ぎません。この種のセキュリティ問題を理解し発見するには、OWASP APIセキュリティトップ10の範囲を超える必要があります。
APIビジネスロジック脆弱性の発見と防止
奇妙なロジックが必ずしも重大な問題を引き起こすとは限りません。しかし、悪用される可能性が見えなくとも、常に修正しなければなりません。
ビジネスロジックの脆弱性を防ぐには、以下の対策が必要です：
- 明確な設計文書を作成する。
- API設計にセキュリティを組み込み、設計段階から安全性を確保する。
- APIのルールと前提条件を文書化する。
- 変更チェック（入力検証やデータ整合性チェックなど）を全面的に実装する。
- ゼロトラストモデルを徹底し、すべてのAPIリクエストを繰り返し認証・検証する。
- サーバーサイド制御を採用する——これは必須である。
ビジネスロジックの脆弱性を発見するには、以下の対応が必要です：
- Equixlyのようなビジネスロジックの脆弱性発見に特化した、スマートで最新の専門セキュリティソリューションを活用し、APIペネトレーションテストやファジングを含む定期的かつ頻繁なAPIセキュリティテストを実施する。
- 異常な動作や不審な動作、異常な動作を検知可能なリアルタイムAPI監視を導入する。
結論
APIビジネスロジックの脆弱性は、セキュリティ問題を引き起こすずさんなロジックや偶発的な論理的欠陥です。このカテゴリーの脆弱性には、クライアントサイド制御への過度な信頼、フィルタリングされていない非標準入力値、不十分なワークフロー検証などの問題が含まれます。
ビジネスロジック関連のインシデントの明確な例としてUSPSデータ漏洩事件が挙げられますが、実際にはさらに多くの事例が日常的に発生していることを認識すべきです。公表され知られるものもあれば、そうでないものもあります。
いずれにせよ、確かなことは一つ：APIロジックの欠陥を根絶しなければならないということです。これを達成するには、サーバーサイド制御、ゼロトラストアプローチ、APIセキュリティテストと監視といった対策を実施する必要があります。
EquixlyがAPIビジネス脆弱性を発見する仕組みと、その実現メカニズムについてぜひお問い合わせください。喜んでご支援いたします。
※この記事はEquixly社ブログを日本語化したものです。
※この記事の無断複写及び転載を禁じます。
※原文：https://equixly.com/blog/2024/08/14/api-business-logic-vulnerabilities/
Carlo De Micheli
Director of Product Marketing
カルロ氏は、豊富な国際経験を持つ多才なプロフェッショナルです。サイバーセキュリティ、自動車、航空宇宙分野など、イノベーションへの情熱は多岐にわたり、先駆的なプロジェクトに積極的に取り組んでいます。航空宇宙工学の技術的バックグラウンドに加え、プログラミングとセキュリティに関する独学も積極的でした。国際会議の企画・発表や、シェアリングエコノミーやファッション関連のテクノロジー系スタートアップの設立を経て、マーケティングとセールスに携わるようになりました。