セキュリティをシフトレフトするということは、APIセキュリティをセキュリティチームだけに任せることはできないということです。開発者は、潜在的な脆弱性を把握し、開発しながら修正する必要があります。DevOpsにセキュリティを組み込むということは、安全で高品質なコードを迅速に提供する方法を考える必要があり、基本的なAPIセキュリティ情報を用意しておくと役に立ちます。
APIは、さまざまな業界における最新のソフトウェア開発の基本的な部分として機能します。開発者を対象とした最近の調査によると、開発者の90.5%が2021年と同程度にAPIを使用すると予想しているのに対し、2022年にはAPIの使用が減ると考えている開発者はわずか3.8%でした。 2022年に2021年よりもAPIへの依存度が高まると予想している開発者の割合が最も高い3つの業界は、ヘルスケア(71%)、テクノロジー(69%)、金融サービス(68%)です。
ニュースになったAPIの脆弱性
APIは、データやシステムへのゲートウェイであるため、継続的なセキュリティ上の懸念を引き起こします。2021年、ロチェスター工科大学の学部生が、より良い学生ローン条件を探していたところ、エクスペリアンの侵害を発見し、自分や誰でも、数千万人のアメリカ人の個人クレジットスコア情報を検索できることを発見しました。ルックアップページの背後にあるコードを調べたところ、貸し手がFICOクレジットスコアのクエリを自動化できるExperian APIが呼び出されていることがわかりました。しかもこのAPIは公開されていたため、クレジットスコアを調べるために適切な許可なしに誰でもそれを使用することができました。
ウクライナ軍がロシア軍に盗まれたJohn Deere社のトラクターを遠隔操作で無力化したというニュースを目にしたことがあるかもしれません 。GPSで追跡してトラクターを遠隔操作で無力化できることに興味を持ったセキュリティ研究者は、開発者アカウントにサインアップし、Deere社のトラクターのVIN番号を所有している人なら誰でもリモートでアクセスできることを発見しました。これは、シノプシスのセキュリティ擁護者であるTaylor Armerding氏が最近のMediumの記事で指摘しているように、米国の食料供給に深刻なリスクをもたらす可能性があります。
金融から農業機械まで、あらゆる分野のビジネスがソフトウェアビジネスである世界ですから、開発者がAPIセキュリティに関する知識を持っていることが不可欠です。
では、使用および生成する API の安全性を確保するにはどうすればよいでしょうか。
OWASP API セキュリティ トップ10
2019年にOWASPが発表したAPI固有の脆弱性トップ10のリストは、けして新しいものではありませんが、振り返る必要があるでしょう。OWASP Top 10 が Web アプリケーションのセキュリティに関する開発者向けの脆弱性情報を標準化しているのと同様に、この特別なリストは、Web アプリケーションに対する最も重要な API セキュリティリスクに関する幅広いコンセンサスを表しています。それぞれについて、なぜそれが問題を引き起こすのかを見てみましょう。
API1:2019 Broken Object-Level Authorization（オブジェクトレベルの認可の不備）
オブジェクトレベルの認可は、ユーザーがアクセスすべきオブジェクトのみにアクセスできることを検証するために、通常はコードレベルで実装されるアクセス制御メカニズムです。 すべての API エンドポイントは、ログインユーザーが要求されたオブジェクトに対して要求されたアクションを実行する権限を持っているかどうかを検証するために、オブジェクトレベルの認可チェックを実装する必要があります。
API2:2019 Broken User Authentication（認証の不備）
認証メカニズムが正しく実装されていない場合、攻撃者が他のユーザーの ID を詐称できる可能性があります。 認証エンドポイントとフローは、パスワードを忘れた場合やパスワードをリセットするシステムなど、保護する必要がある資産です。 パスワード・リセット・プロトコルが後付けの場合、ユーザー認証攻撃に対する豊富な攻撃対象領域が形成されます。
API3:2019 Excessive Data Exposure（データの過剰な公開）
開発者はデフォルトですべてのオブジェクトプロパティを公開し、ユーザーに表示する前にデータフィルタリングを実行するようクライアントに依存する傾向があります。悪意のある攻撃者は、トラフィックを盗聴して APIレスポンスを分析することでこの弱点を利用し、ユーザーに返すべきではない機密データの曝露を探し出します。
API4:2019 Lack of Resources and Rate Limiting（リソース不足と帯域制限）
APIでは、クライアントまたはユーザーが要求できるリソースのサイズや数に制限を設けていないことがよくあります。APIリクエストは、ネットワーク、CPU、メモリ、ストレージなどのリソースを消費してAPIサーバーのパフォーマンスに影響を及ぼし、サービス拒否 (DoS) につながる可能性があるだけでなく、ブルートフォース（総当たり）などの認証攻撃に対するドアも開いたままにします。
API5:2019 Broken Function-Level Authorization（機能レベルの認可の不備）
認可の不備は、異なる階層、グループ、およびロールを持つ過度に複雑なアクセス制御ポリシーや、管理機能と通常の機能の分離が不明瞭であることが原因である可能性があります。悪意のあるアクターは、不正な機能にアクセスするために、アクセスできないはずのAPIエンドポイントに正当なAPI呼び出しを送信することで、この欠陥を悪用します。管理機能は、この種の攻撃の主要な標的です。
API6:2019 Mass Assignment（一括割り当て）
モダンなフレームワークでは、開発者は、クライアントからの入力をコードの変数と内部オブジェクトに自動的にバインドする関数を使用することを奨励しています。APIは、アプリケーションの基になる実装をプロパティ名と共に公開するため、攻撃者はこの手法を使用して、開発者が公開することを意図していなかった機密性の高いオブジェクトプロパティを更新または上書きできます。悪用されると、権限昇格、データの改ざん、セキュリティメカニズムのバイパスなどにつながる可能性があります。
API7:2019 Security Misconfiguration（セキュリティ設定ミス）
セキュリティの設定ミスは、ネットワークレベルからアプリケーションレベルまで、APIスタックのあらゆるレベルで発生する可能性があります。攻撃者は、多くの場合、パッチが適用されていない欠陥、一般的なエンドポイント、または保護されていないファイルやディレクトリを見つけて、システムへの不正アクセスや知識を取得しようとします。セキュリティの設定ミスにより、機密性の高いユーザーデータやシステムの詳細が漏洩し、サーバー全体の侵害につながる可能性があります。
API8:2019 Injection（インジェクション）
インジェクションの欠陥は、信頼できないデータがコマンドまたはクエリの一部としてインタープリタに送信された場合に発生します。攻撃者の悪意のあるデータは、インタプリタを騙して意図しないコマンドを実行したり、適切な許可なしにデータにアクセスしたりする可能性があります。インジェクションは、情報漏えいやデータ損失につながる可能性があります。また、DoS や完全なホスト乗っ取りにつながる可能性もあります。これが、インジェクションが一般的なOWASP Top 10で3番目に重大なセキュリティ問題として挙げられている理由です。
API9:2019 Improper Assets Management（不適切な資産管理）
通常、古いバージョンのAPIにはパッチが適用されていません。これにより、最新バージョンのAPIを保護するために導入されている可能性のある最先端のセキュリティメカニズムと戦うことなく、システムを容易に侵害できます。攻撃者は、機密データにアクセスし、同じデータベースに接続されたパッチが適用されていない古いバージョンのAPIを介してサーバーを乗っ取ることもできます。
API10:2019 Insufficient Logging and Monitoring（不十分なロギングとモニタリング）
ログ記録と監視が不十分な為、インシデント対応との統合が欠落していたり、効果がなかったりすると、攻撃者はシステムをさらに攻撃し、継続性を維持し、改ざんするシステムを増やし、データを抽出または破壊することができます。ほとんどの侵害の調査では、侵害を検出するまでに200 日以上かかっていることが示されており、往々にして、内部プロセスや監視ではなく、外部関係者によって発見されます。進行中の悪意のあるアクティビティを可視化できないため、攻撃者はシステムを完全に侵害するのに十分な時間を得ることができます。詳細については、「ロギングと監視のための、７つのベストプラクティス」をご覧ください。
認証と認可は API セキュリティの鍵です
OWASP API Security Top 10 リストの半分以上が認証と認可に関連していることは間違いありません。これらの欠陥は、APIシステムがハッキングされる最も一般的に悪用されるのです。
認証と認可は2つの個別のプロセスであることを覚えておくことが重要です。認証は、ユーザーが誰であるかを確認するプロセスで、認可は、何にアクセスできるかを確認するプロセスです。
API はユーザーの認証に依存してどの認可の権限を付与するかを決定するため、API 認証を正しく取得することが重要です。 API 認証プロトコルを設定するときに留意すべき点の 1 つは、クライアントはマシンであるため、(せっかちな) 人間のユーザーよりもはるかに頻繁に認証を要求できることです。
eBook
APIセキュリティの現状のeBookを読む
Continue Reading
The cybersecurity landscape - A discussion of future state and AI with Dr. Lisa Bradley
Feb 21, 2024 / 1 min read
