上位の OATH API 脆弱性
上位の OATH API 脆弱性: 概要
エクスプロイトに関して言えば、API は出発点として最適です。 API アクセスは通常、XNUMX つの部分で構成されます。 クライアントは、API と並行して実行される認可サーバーによってトークンが発行されます。 API はクライアントからアクセス トークンを受け取り、それに基づいてドメイン固有の承認規則を適用します。
最新のソフトウェア アプリケーションは、さまざまな危険に対して脆弱です。 最新のエクスプロイトとセキュリティ上の欠陥について最新の情報を入手してください。 これらの脆弱性のベンチマークを持つことは、攻撃が発生する前にアプリケーションのセキュリティを確保するために不可欠です。 サードパーティ アプリケーションは、ますます OAuth プロトコルに依存しています。 このテクノロジーのおかげで、ユーザーは全体的なユーザー エクスペリエンスが向上し、ログインと認証が高速化されます。 ユーザーは、特定のリソースにアクセスするためにサードパーティ アプリケーションで資格情報を開示する必要がないため、従来の承認よりも安全な場合があります。 プロトコル自体は安全ですが、実装方法によっては攻撃にさらされる可能性があります。
API を設計してホストする場合、この記事では、典型的な OAuth の脆弱性と、さまざまなセキュリティの軽減策に焦点を当てます。
壊れたオブジェクトレベルの認証
API はオブジェクトへのアクセスを提供するため、承認に違反すると、攻撃対象が膨大になります。 API アクセス可能なアイテムは認証する必要があるため、これが必要です。 API ゲートウェイを使用して、オブジェクト レベルの承認チェックを実装します。 適切な権限資格証明を持つユーザーのみがアクセスを許可される必要があります。
壊れたユーザー認証
未承認のトークンは、攻撃者が API へのアクセスを取得するためのもう XNUMX つのよくある方法です。 認証システムがハッキングされたり、API キーが誤って公開されたりする可能性があります。 認証トークンは ハッカーによって使用される アクセスを取得します。 信頼できる場合にのみ人を認証し、強力なパスワードを使用します。 OAuth を使用すると、単なる API キーを超えてデータにアクセスできます。 場所に出入りする方法を常に考えておく必要があります。 OAuth MTLS Sender Constrained Tokens を相互 TLS と組み合わせて使用することで、クライアントが他のマシンにアクセスしているときに不正な動作をしたり、トークンを間違った相手に渡したりしないことを保証できます。
API プロモーション:
過剰なデータ漏洩
公開できるエンドポイントの数に制限はありません。 ほとんどの場合、すべてのユーザーがすべての機能を利用できるわけではありません。 絶対に必要な以上のデータを公開することで、自分自身や他の人を危険にさらすことになります。 機密情報の開示を避ける 情報 どうしても必要になるまで。 開発者は、OAuth スコープとクレームを利用して、誰が何にアクセスできるかを指定できます。 クレームは、ユーザーがアクセスできるデータのセクションを指定できます。 アクセス制御は、すべての API で標準構造を使用することにより、よりシンプルで管理しやすくなる場合があります。
リソース不足とレート制限
ブラック ハットは、サービス拒否 (DoS) 攻撃を、サーバーを圧倒してアップタイムをゼロにする力ずくの方法として使用することがよくあります。 呼び出すことができるリソースに制限がないため、API は衰弱攻撃に対して脆弱です。 「API ゲートウェイまたは管理ツールを使用して、API のレート制限を設定できます。 フィルタリングとページネーションを含め、回答を制限する必要があります。
セキュリティ システムの設定ミス
セキュリティ設定の誤りが発生する可能性が非常に高いため、さまざまなセキュリティ設定ガイドラインがかなり包括的です。 ささいなことで、プラットフォームのセキュリティが危険にさらされる可能性があります。 例として、不正な目的を持つブラック ハットが、不正な形式のクエリに応答して送信された機密情報を発見する可能性があります。
一括割当
エンドポイントがパブリックに定義されていないからといって、開発者がアクセスできないわけではありません。 秘密の API は、ハッカーによって簡単に傍受され、リバース エンジニアリングされる可能性があります。 「プライベート」API でオープン ベアラー トークンを使用するこの基本的な例を見てください。 一方、公開文書は、個人的な使用のみを目的としたもののために存在する場合があります。 公開された情報は、ブラック ハットによって読み取られるだけでなく、オブジェクトの特性を操作するためにも使用される可能性があります。 防御の潜在的な弱点を探すときは、自分がハッカーであると考えてください。 適切な権限を持つユーザーだけが、返されたものにアクセスできるようにします。 脆弱性を最小限に抑えるには、API 応答パッケージを制限します。 回答者は、絶対に必要でないリンクを追加しないでください。
プロモートされた API:
不適切な資産管理
開発者の生産性を高めるだけでなく、現在のバージョンとドキュメントはユーザー自身の安全のために不可欠です。 新しいバージョンの導入と古い API の廃止に備えて、かなり前もって準備してください。 古い API をそのまま使用するのではなく、新しい API を使用してください。 API 仕様は、ドキュメントの信頼できる主要な情報源として使用できます。
注射
API はインジェクションに対して脆弱ですが、サードパーティの開発者アプリも同様です。 悪意のあるコードを使用して、データを削除したり、パスワードやクレジット カード番号などの機密情報を盗んだりする可能性があります。 ここから学ぶべき最も重要な教訓は、デフォルト設定に依存しないことです。 管理者またはゲートウェイ サプライヤは、独自のアプリケーション ニーズに対応できる必要があります。 エラー メッセージに機密情報を含めないでください。 ID データがシステム外に漏洩するのを防ぐために、ペアワイズ仮名をトークンで使用する必要があります。 これにより、クライアントが連携してユーザーを識別できないことが保証されます。
不十分なロギングとモニタリング
攻撃が発生した場合、チームはよく考え抜かれた対応戦略を必要とします。 信頼できるログ記録および監視システムが導入されていない場合、開発者は、発見されることなく脆弱性を悪用し続けます。これにより、損失が増加し、企業に対する一般の認識が損なわれます。 厳格な API モニタリングと本番エンドポイント テスト戦略を採用します。 早期に脆弱性を発見したホワイト ハット テスターには、報奨金制度が与えられるべきです。 ログ証跡は、ユーザーの ID を API トランザクションに含めることで改善される場合があります。 アクセス トークン データを使用して、API アーキテクチャのすべてのレイヤーが監査されるようにします。
まとめ
プラットフォーム アーキテクトは、確立された脆弱性基準に従って、攻撃者の一歩先を行くようにシステムを装備する場合があります。 API は個人を特定できる情報 (PII) へのアクセスを提供する場合があるため、そのようなサービスのセキュリティを維持することは、会社の安定性と GDPR などの法律への準拠の両方にとって重要です。 API Gateway と Phantom Token Approach を使用せずに、OAuth トークンを API 経由で直接送信しないでください。
プロモートされた API:
