API 攻撃におけるボットの役割

API は、最新のアプリケーションの構成要素であり、構成可能なエンタープライズ モデルとデジタル プラットフォームを推進します。 API 統合の重要性を認識する組織が増えるにつれ、API の使用は急増しています。

現在、世界中で使用されているパブリック API とプライベート API の総数は、約2 億と推定されています。 API は非常に重要で設計されているため、データ、リソース、および機能にすばやく簡単にアクセスできます。攻撃者がそれらを見逃すことはありません。ボットは攻撃者にとって重要なツールであり、ボットを利用して API ボット攻撃を調整しています。

API ボット攻撃とは正確には何ですか?攻撃者はどのようにボットを使用してAPIを攻撃しますか? API をボットからどのように保護しますか?読み続けて調べてください。

API ボット攻撃

API ボット攻撃とは何かを掘り下げる前に、まずボットの基本を理解しましょう。

ボットは、マシン間の通信に使用される自律型プログラムです。それらは、人間の介入なしで機能を実行し、Web 要求を実行するようにプログラムできます。 IP アドレスからシステムに HTTP トラフィックを送信します。ボットネットは、連携して複数の IP アドレスを利用できるボットの集まりです。ボットネットの規模は、数百から数千の IP アドレスまでさまざまです。

ボット攻撃では、悪意のあるアクターがボットを利用して、標的の Web サイト、アプリ、エンド ユーザー、または API を操作、詐欺、または妨害します。ボット攻撃は当初、標的をスパムするために使用されていました。しかし今日では、それらははるかに洗練されており、人間の行動によく似た複雑な攻撃を実行できます。

これらの自動化されたプログラムが特定の API を攻撃するために利用される場合、または攻撃者がボットを利用して API 攻撃の規模、影響、および洗練度を高める場合、それは API ボット攻撃です。

ボットが API に対して使用されるのはなぜですか?

データ、リソース、およびビジネス ロジックのプログラムによる公開:

ボットは、長年にわたってサイバー攻撃に使用されてきました。しかし、それらが API に対して使用される場合、なぜ懸念の原因になるのでしょうか?これは、API がさまざまなアプリを接続し、データやリソースなどへのプログラムによるアクセスを提供し、複数のクライアントによる簡単な統合と共有を可能にするように設計されているためです。その性質上、価値の高い機能とビジネス ロジックを公開し、リソースを見つけやすくします。したがって、機密情報にさらされるリスクが高まります。

可視性の欠如:

組織はライフサイクル全体で API を可視化できないため、API はボット攻撃の格好の標的となります。そして、彼らが舞台裏で働いているという事実は、あまり役に立ちません。アーキテクチャに API が存在することを知らない場合、それらをどのように精査、管理、保護しますか?これにより、いくつかの脆弱な、シャドウ、ゾンビ、不正、および不適切に構成された API が残ります。その結果、従来のエンドポイントよりも安全性が低くなることが多く、リスクが指数関数的に増加します。

このミックスにボットを追加すると、災害のレシピがあります。組織は、どの API が存在するか、誰がそれらを使用しているか、どのリソースにアクセスできるか、どのようなビジネス ロジックを公開しているかを把握していない可能性があります。しかし、攻撃者はボットを利用して組織の IT アーキテクチャをマッピングし、API の弱点を探し回っています。ボットは実際に、攻撃者にとってプロセスを迅速、簡単、機敏にします。

今日のボットはステルスです。

ボットは非常にステルスであり、従来のセキュリティ ツールによる検出を回避できるため、API 攻撃にも使用されます。実際、今日のより洗練されたボットは、より高度なセキュリティ ツールによる検出を回避することもできます。

たとえば、API 認証ルールを一時的に調整して、ログイン試行が 3 回失敗した後にアカウントを凍結した可能性があります。ボットは、クレデンシャル スタッフィング攻撃の試行が 2 回失敗すると、単純に別の IP アドレスに切り替えます。インテリジェントな自動化を使用して、人間の介入なしにこれらすべてを実行し、プログラムされたルールと時間の経過に伴う学習に基づいて外出先で意思決定を行います。

ボットは、他の攻撃の煙幕として使用されます。

API ボット攻撃は、他の種類の API 悪用を調整しようとする攻撃者によって、注意散漫や煙幕として使用されることがよくあります。たとえば、攻撃者はボットネットを利用して、セキュリティ チームがフォローアップするために何千ものセキュリティ アラートをトリガーする可能性があります。しかし、彼らの意図は、セキュリティ チームがセキュリティ アラートを調査している間に ID を列挙することです。

攻撃者はボットを利用して API を攻撃します。これは、ボットがプロセスにおいて比類のない速度、柔軟性、俊敏性を提供するためです。たとえば、クレデンシャル スタッフィングやブルート フォース攻撃は、セキュリティ防御を突破せずに手動で行うことはできません。しかし、ボットはブルート フォースと Credential Stuffing を迅速、簡単、かつスケーラブルにします。

攻撃者が API を標的にするのにボットがどのように役立つかを示す別の例を次に示します。攻撃者は、認証なしでエンドポイントに大量の API リクエストを送信し、短時間で大量のデータを収集する可能性があります。

従来のツールは、現代のボットに対して効果がありません。

従来のセキュリティ ツールは、通常のボット攻撃でも不足していることが判明しています。しかし、API 専用に設計されていないため、API ボット攻撃を阻止する効果はありません。第一に、従来のツールでは、ボットと人間の活動、およびボットの活動の良し悪しを効果的に区別することができません。これにより、ボットベースの攻撃から API を保護する能力が大幅に制限されます。

次に、ボットが残す手がかりや API が収集する詳細情報が少ないため、従来のツールでは、API 呼び出しが悪意のあるものか正当なものかを効果的に判断できません。基本的に、ボットはブラウザ攻撃の場合と同じデータを要求します。

違いは、API ボット攻撃では、ボットの活動を検出するために従来のツールで使用されていたブラウザーのバージョン、使用されている Cookie、デバイスの種類などに関する情報が得られないことです。 API 攻撃は完全に仮想的なものであるため、ボットは攻撃を回避したり、異なるクラウド間を移動したり、IP アドレスをローテーションしたり、プロキシ ネットワークを使用したりして、従来の防御を打ち破るためにさらに多くのことを行うことができます。

ビジネス ロジックの欠陥:

開発者は一般的なルールセットを使用し、ビジネス ロジックを考慮せずに API をデフォルト設定のままにしておく傾向があります。これにより、一見正当な API リクエストによって検出を回避しながら、ボットが大混乱を引き起こすために利用できるビジネス ロジックの欠陥が作成されます。

API に対するボット攻撃は簡単に実行できます。

API に対するボット攻撃は、モバイル アプリケーションや Web アプリケーションに対するボット攻撃よりもはるかに簡単に調整でき、費用対効果も高くなります。異なるアプリには異なるアプローチとボット機能が必要ですが、攻撃者はダイレクト API と Web API に同じインフラストラクチャと攻撃メカニズムを使用できます。さらに、API を使用すると、攻撃者はコア IT インフラストラクチャと重要な資産にさらに接近してアクセスできます。

さらに、ボット、ボットネット、攻撃ツールキットはレンタルで簡単に入手でき、多くの場合低価格です。そのため、攻撃者は、API ボット攻撃を仕掛けるために多くのリソースや深い技術知識を必要としません。

ボットは API 攻撃でどのように使用されますか?

1. 偵察:攻撃者はボットとボットネットを利用して、脆弱な API エンドポイントを発見し、検出しきい値をテストし、攻撃対象領域をマッピングします。

2. 攻撃:ボットとボットネットを使用して API を攻撃します。一般的な API ボット攻撃には、クレデンシャル スタッフィング、ブルート フォース攻撃、コンテンツ スクレイピング攻撃、インジェクションなどがあります。

3. 回避: API ベースの攻撃では、攻撃者がボットとボットネットを利用して、ステルスな動作や気を散らすことによってセキュリティ防御を回避します。

   
   

API ボットの緩和: 5 つの効果的な方法

• インテリジェンスを収集し、API に関するボットの通常の動作のベースラインを構築します。
• 受信するすべての API リクエストを監視して、偵察段階で異常な動作を発見して停止します。
• 導入されたセキュリティ ツールは、人的介入をあまり必要とせずに、ケースバイケースで着信トラフィックをインテリジェントに許可、ブロック、フラグ、またはチャレンジできる必要があります。
• 行動とパターンの分析、ワークフローの検証、フィンガープリンティングを活用して、ボットの人間の活動、良い活動、悪い活動を効果的に区別します。
• 設定ミス、脆弱性、ビジネス ロジックの欠陥がないか、API のスキャン、テスト、監視を続けます。
• ゼロトラスト ポリシーでアクセス制御と認証メカニズムを強化します。
• 常に API ルールセットをカスタマイズします。