1,000 件のデータ漏洩による死亡: API がセキュリティを圧倒するしくみ

公開: 2022-06-14

今日の攻撃対象領域はかつてないほど広がっており、アプリから脆弱性が浸透し、テクノロジーの世界を動かしている柔軟なアプリケーションプログラミングインターフェースに生息しています。

残念ながら、ほとんどの人が従来の Web アプリの脅威を認識していますが、API は依然としてセキュリティの曖昧な領域です。今日の巨大な脅威の状況では、有能なクラウド WAF と WAAP への投資さえも必要としています。

API とは何ですか?

API は、最新のブラウジングエクスペリエンスをまとめるための接着剤です。 API は、個々の Web アプリがデータを交換できるようにすることで、ソフトウェアの使用と開発を簡素化します。適切に実装された API は非常に安全であるという事実のおかげで、アプリを介してサーバーにリクエストを行うことは、最近では関連する API によって処理されます。

サーバーがユーザーの情報に直接さらされるのではなく、デバイスと関連する API がデータの小さなパケットを共有し、必要なものだけを通信する必要があります。

アジャイルと API: セキュリティの二重の問題

アジャイルは、往年のビジネスの流行語です。これは、「実行可能な最小限の製品」という起業家のアイデアを増幅する生産形態を表しています。アジャイルの目標は、各段階で最小限の製品を押し出すことです。製品を「完成」と呼ぶのではなく、バグの修正と改善にパッチを適用するためのさらに別のラウンドにループするだけです。

この永続的なパッチ適用はセキュリティ上は素晴らしいように思えますが (継続的なソフトウェアサポート? いいですね!) ソフトウェア生産の経済的な現実は、API の量がすぐに扱いにくくなることを意味します。

開発チームの動きが速いため、API が包括的に文書化されることはめったにありません。これにより、アプリの内部メカニズムを詳しく調べて、どの API が何を行っているかを理解することが非常に困難になります。また、開発チーム自身が API インベントリの実際のサイズを把握していないため、セキュリティが非常に難しくなります。これにより、サイバーセキュリティの優先度が低くなります。常に反応的で、積極的ではありません。

見落とされた API

アプリのセキュリティについて言及すると、最初に頭に浮かぶのはセキュリティの重鎮です。クロスサイトスクリプティングなどの攻撃。 SQL インジェクションと DDoS 攻撃はすべて非常によく知られています。多くの場合、アプリケーション自体は、境界をパトロールする Web アプリケーションファイアウォールなどのプラグアンドプレイソリューションによって適切に保護されています。

API にはほとんど注意が払われておらず、無知な組織とそのクライアントに多大な損害を与えています。 Uber のシステムで発生した API の脆弱性の例を見てみましょう。

Uber ドライバーが紹介リンクを介して Uber に参加すると、アプリを起動して紹介コードを入力します。 Enter ボタンを押すと、アプリブラウザーは API ホスト「bonjour.uber.com」と通信します。そこから、bonjour.uber はユーザー ID パラメーターを受け取り、ドライバーに関する詳細をユーザーのアプリに返し、次の同意画面に入力できるようにします。

しかし、この 1 つの API は 2 つの重大なセキュリティ侵害で有罪判決を受けました。 1 つ目は、Broken Object Level Authorization (BOLA) でした。 API は、ユーザーの ID が ID パラメーターと一致することを確認しませんでした。そのため、ユーザー ID を変更するだけで、他のユーザーのデータにアクセスできました。

2 つ目の問題は、過度のデータ漏洩でした。 API の応答 (ユーザーの詳細を返す) では、すべての情報が 1 つのバッチにまとめられ、ユーザーの詳細がすべて含まれていました。これは、クライアントが明示的に必要としていない情報を API が返すことを意味し、サイバーセキュリティのベストプラクティスの主要な柱に違反していました。

ここで、平均的な組織が 15,500 を超える API に依存しており、リスクの規模が明らかになり始めていると考えてみてください。ありがたいことに、大きな損害が発生する前に Uber API がプラグインされました。次の会社はそれほど幸運ではありませんでした。

ペロトンの問題

Peloton の在宅フィットネスブランドは、300 万人以上の加入者が楽しんでいます。ライブフィットネスクラスは大きなセールスポイントですが、医療データを他のクラス参加者と共有したくない場合は、peloton アカウントを非公開に設定することができます。

残念ながら、多くの API の脆弱性により、このデータが許可されていないユーザーに公開されました。 1 つの API エンドポイントが要求しているユーザーの検証に失敗したため、クラスの出席者の情報が大規模にスクレイピングされる可能性がありました。これにより、権限のない攻撃者が Peloton ユーザーのユーザー名、場所、ワークアウト ID、性別、年齢を取得することができました。

API は、何年もの間、注目を集めるデータ漏洩の原因となってきました。 2018 年から 2019 年にかけての Facebook の絶え間ないデータスキャンダルでは、主にサードパーティの開発者 API を介して、次から次へと侵害が発生しました。その一例が Groups API です。 B2B ソーシャルメディア管理アプリに取り組んでいる開発者は、グループメンバーの名前やその他の個人情報に自由にアクセスできます。このソーシャルメディア管理アプリは、グループ管理者がグループをより効果的に管理できるようにすることを目的としていましたが、Facebook はそれとその API を削除する必要がありました。

これらのデータスキャンダルは 2021 年に最高潮に達し、5 億 3,300 万人を超える Facebook ユーザーのブラックマーケットデータベースから名前、電話番号、Facebook ユーザー ID が流出しました。

API 漏洩の防止

Open Web Application Security Project (OWASP) は、最も深刻で広まっている Web アプリの脆弱性を定期的に公開しており、注意が必要です。 API に代表される増大するセキュリティの脅威は、独自の OWASP トップ 10 リストを正当化するのに十分なほど深刻であり、Broken Object Level Authorization が一貫してトップになっています。

ありがたいことに、API を保護することは、開発サイクルを遅くすること以外に、組織全体を保護することと密接に関係しています。最初の呼び出しポイントは、適切な Web アプリケーションファイアウォール (WAF) です。このソリューションはアプリの境界を監視し、API ゲートウェイが主要な脆弱性によって悪用されるのを防ぎます。

Web アプリケーションと API の保護 (WAAP) は、さらに一歩先を行くものです。アプリの公開境界に完全に位置し、すべての着信トラフィックを分析します。 WAAP は、正当なトラフィックとリクエストのパターンを監視することにより、API を保護するために特別に設計された高度に専門化されたセキュリティツールです。

WAAP はエンドポイントレベルの防御システムですが、Runtime Application Self Protection (RASP) ソリューションは特定の Web アプリをラップします。 WAF とは異なる RASP ソリューションも、そのアプリケーションの内部の仕組みと動作に関する洞察を持っています。このように、API が攻撃の足がかりとして使用され、実行可能なよりも多くの情報を照会された場合、RASP は積極的に攻撃をシャットダウンできます。

無数の API 保護オプションを利用できるため、アプリと組織を保護することがかつてないほど容易になります。