API の 5 つの一般的な脆弱性は何ですか?

API を使用するとビジネスが簡単になり、ハッカーもそう考えています。企業のデジタル トランスフォーメーションが本格化している今日、API はテクノロジーの範囲をはるかに超えており、インターネット ビジネスのイノベーションと従来の企業のデジタル トランスフォーメーションはいずれも API エコノミーまたは API 戦略と切り離せないものとなっています。 API は、システムとデータだけでなく、企業の機能部門、顧客やパートナー、さらにはビジネス エコシステム全体を接続します。同時に、セキュリティの脅威がますます深刻になる中、API はネットワーク セキュリティの次のフロンティアとなりつつあります。 私たちは、セキュリティ専門家が企業に提供した上位 5 つの API セキュリティの弱点とパッチ適用の提案をまとめました。

API を使用すると、データ共有からシステム接続、重要な機能の提供に至るまで、すべてが簡単になりますが、悪意のあるボットなどの攻撃者にとっても API は簡単になります。 API アプリケーションの急増により、サイバー犯罪者が API のセキュリティの脆弱性を悪用して詐欺を行ったり、データを盗んだりする傾向が強くなっています。

以下では、ハッカーによって簡単に悪用される 5 つの API の脆弱性について説明し、セキュリティの専門家による軽減策と強化の提案を共有します。

1. 発見されにくいハッカーである場合、最初に行う必要があるのは、多くのハッカーを特定することです。可能な限り API 。まず、対象のアプリケーションを通常の方法で使用し、ブラウザで Web アプリケーションを開くか、携帯電話にモバイル アプリケーションをダウンロードしてインストールします。次に、傍受プロキシを使用して通信を監視します。

インターセプト プロキシは、ブラウザまたはモバイル アプリケーションによってバックエンド Web サーバーに対して行われたすべてのリクエストをキャプチャできるため、攻撃者は利用可能なすべての API エンドポイントをカタログ化できます。たとえば、ほとんどの API には認証エンドポイントとして API/V1/login があります。

ターゲットもモバイル アプリの場合は、アプリを解凍し、アプリ内で使用できる API 呼び出しを確認します。攻撃者は、考えられるすべてのアクティビティを考慮して、ユーザー データを適切に保護できない一般的な構成エラーや API を検索できます。

最後に、攻撃者は API ドキュメントを探します。一部の組織はサードパーティ向けに API ドキュメントを公開していますが、すべてのユーザーに対して同じ API エンドポイントを使用しています。

適切なエンドポイント リストを使用すると、攻撃者は標準的なユーザーの動作テストと異常な動作のテスト、つまり興味深い脆弱性を見つける 2 つの方法をテストできます。

回避策:

攻撃者による API の発見をより困難にするには、有効なユーザーのみにアクセスを許可する権限管理を通じて、API ドキュメントへのアクセスを必ず制御してください。証明書をモバイル アプリに固定しても API エンドポイントが完全に隠蔽されるわけではなく、完全ではありませんが、攻撃に追加の手順が追加されます。 Web サーバーへの API リクエストは、可能な限り難読化して制御する必要があります。

2. 詳細すぎるエラー メッセージ

最近、攻撃者によるアカウント乗っ取りの試みが増加しています。エラー メッセージが「詳細」すぎると、このような攻撃が容易になる傾向があります。長いエラー メッセージは、正当なリクエストとして見せるためにどのような変更を加える必要があるかを攻撃者に指示します。この API は、低負荷での高速トランザクション向けに設計されており、攻撃者が高性能システムを使用して有効なアカウントを識別し、ログインしてパスワードを変更して悪用することを可能にします。

解決策:

ユーザー エクスペリエンスを盾として使用しないでください。ユーザー エクスペリエンスにとって有益であると思われる実践の中には、セキュリティにとって有益ではないものもあります。システムから返されるエラー メッセージには、間違ったユーザー名や間違ったパスワード、さらにはエラー メッセージのカテゴリ (間違ったユーザー名やパスワード) が含まれていてはなりません。データのクエリに使用されるエラー メッセージにも同様のことが当てはまります。クエリや検索の形式が正しくない場合、または何らかの理由で実行できない場合は、「おっと、問題が発生しました」という最も「栄養価の低い」エラー メッセージが返されるはずです。

3. パラメーターが多すぎます

攻撃者が API 呼び出しを通じて攻撃システムを横断する場合、データを取得するために何を送信できるかを把握する必要があります。攻撃者は、システムが複雑になればなるほど、より多くの問題が発生する可能性があると「信じています」。攻撃者は API を特定すると、パラメータをカタログ化し、管理者 (垂直権限エスカレーション) または別のユーザー (水平権限エスカレーション) のデータにアクセスして追加データを収集しようとします。多くの場合、不要なパラメーターが多すぎてユーザーに公開されます。

最近の調査プロジェクトでは、ターゲット サービスへの API 呼び出しにより大量のデータが返されました。その多くは、支払いゲートウェイ プロセッサ キーや利用可能な割引情報などの不要なデータ情報でした。この「報酬情報」により、攻撃者はこれらの API 呼び出しのコンテキストと構文をより深く理解できるようになります。攻撃者が次に何をすべきかを判断するのに、それほど想像力は必要ありません。これらの追加パラメーターは、攻撃者に豊富な攻撃データ セットを提供します。

解決策:

ユーザーが閲覧するコンテンツの範囲を必要なコンテンツに限定し、重要なデータの送信を制限し、データのクエリ構造を不明にすると、攻撃者がそれを知るのは困難になります。ブルートフォースクラッキング用のパラメータについて。

4. データが多すぎます

繰り返しますが、非常に多くのパラメータが利用できるため、データの収集が次のステップとなることは明らかです。多くの企業システムは匿名接続をサポートしており、平均的なユーザーには必要のない追加データが漏洩する傾向があります。さらに、多くの企業は、直接アクセスできるデータを保存することを好みます。

セキュリティ専門家は、データの保存場所が公開されることが多い API リクエストという課題に取り組んでいます。たとえば、セキュリティ カメラのビデオを見ると、その情報が Amazon S3 リポジトリから取得されていることがわかります。多くの場合、これらの S3 リポジトリは十分に保護されておらず、誰のデータも取得できる可能性があります。

データに関するもう 1 つの一般的な課題は、データの過負荷です。多くの企業は冬の前のシマリスのように、必要以上のデータを保存しています。期限切れのユーザー データの多くには商業的価値も保存価値もありませんが、漏洩すると企業に大きなブランド リスクやコンプライアンス リスクをもたらします。

解決策: PII や PHI だけでなく、ユーザー データを保存する企業の場合は、徹底的なデータ レビューが必要です。保存されたデータを検査した後、データ アクセス ルールを開発してテストする必要があります。匿名でアクセスできるデータには機密データが含まれていないことを確認してください。

5. セキュリティ設計が不十分すぎる

長年にわたり、アプリケーション設計では常に機能と使いやすさが優先され、セキュリティはほとんど考慮されていませんでした。多くの CISO は、特に API セキュリティが真剣に考慮されていない、あるいはセキュリティ設計プロセスから完全に除外されていることさえあると述べています。通常、開発者は開発とデプロイメントを完了した後、API が運用環境に導入され、頻繁に攻撃されるようになって初めて問題を見つけようとします。 セキュリティ (API セキュリティを含む) は、後から穴埋めするのではなく、製品設計の一部として最初の考慮事項の 1 つとして実装する必要があります。

解決策: アプリケーションのセキュリティ アーキテクチャを確認することは、安全なシステムへの重要な第一歩です。 API を使用すると、攻撃者はシステムをより効率的に攻撃または悪用できるようになります。セキュリティ設計の目標は、API を攻撃者ではなくユーザーにとって効率的なツールにすることです。

以上がAPI の 5 つの一般的な脆弱性は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。