2021年のAPIセキュリティ - トップ10のベストプラクティス

APIとは何か？

WiFiやマイクロ波のような見えない電波が私たちを取り巻くという話はよく聞かれますが、インターネットの登場とともに、エンジニアは冷蔵庫でフラッピーバードを遊び、そのハイスコアをサーバに送る仕組みが必要になったという事実はあまり語られていません。

冗談はさておき、APIはあらゆるところに存在しています。APIはアプリプログラミングインタフェースの略ですが、直感的にはその意味を考え直す必要があります。基本的には、APIは2つのアプリが通信するための仕組みです。この定義なら、なぜAPIが広く使われているかが理解できます。現在では、多くのウェブサイトがAPIと連携しており、インターネットに接続されたほとんど全てのものは動的で、APIとの通信が必要です。

SOAPとREST

SOAPとRESTは、それぞれ異なるセキュリティアプローチを必要とするため、その違いを理解することが重要です。SOAPはシンプルオブジェクトアクセスプロトコル、RESTは表現状態転送の略です。SOAPが先に設計され、その後RESTが登場しました。つまり、SOAPはプロトコルであり、RESTはアーキテクチャパターンです。アーキテクチャパターンは、特定の文脈における一般的で再利用可能な解決策である一方、プロトコルは異なるデバイスやAPI間でデータを送受信するための規則が定められたものです。

技術的には、SOAPはXML形式のみで動作し、RESTはプレーンテキスト、XML、HTML、JSONで動作します。また、GET、POST、PUT、DELETEといったHTTP動詞を利用して必要な処理を実行します。SOAPではWSDL文書によりAPIとの通信仕様が定義され、RESTはURLを頼りに正しいデータを取得します。

RESTの大きな利点は、通常JSONを使用するため、帯域幅を節約できる点にあります。一方、SOAPはXMLに限定され、多くの余計な情報が付加されるためです。

{"name":"Actor","Country":"Belgium"}

<?xml version="1.0"?>
<SOAP-ENV:Envelope 
    xmlns:SOAP-ENV="<http://www.w3.org/2001/12/soap-envelope>"
    SOAP-ENV:encodingStyle=" <http://www.w3.org/2001/12/soap-encoding>">
    <soap:Body>
        <Demo.thexssrat.com xmlns="<http://thexssrat.org/>">
            <name>Actor</name>
            <Country>Belgium</Country>
        </Demo.thexssrat.com>
    </soap:Body>
</SOAP-ENV:Envelope>

なお、RESTはステートレスなアーキテクチャであるため、各機能間で状態情報は引き継がれません。もし状態の引き継ぎが必要な場合は、SOAPプロトコルを利用する必要があります。

今日、組織が直面する主要なAPIセキュリティ課題

近年、企業はインフラのセキュリティ向上に大きな進歩を遂げましたが、依然として解決すべき課題は多く残っています。特に、情報自体の不足が大きな脅威となっています。プログラムは多くのマイクロAPIで構成され、相互に通信するため、安全対策が後回しにされたり全体が見落とされたりしがちです。企業はこの点で、細心の注意を払わなければなりません。

セキュリティ対策に十分な時間を割くことは大切ですが、管理が行き届かないと大きな負担となります。全API構造や考えられる攻撃経路を常に把握し、システムや各構成要素に過度な負荷をかけないようにする必要があります。どのAPIが稼働中でどのエンドポイントを公開しているかを確認し、攻撃経路を整理することは容易な作業ではなく、手作業では圧倒される可能性があります。

‍

Web APIに対する一般的な攻撃

1. インジェクション攻撃

APIに対する攻撃の一例として、インジェクションがあります。これはコマンドインジェクションやSQLインジェクションなどが含まれ、その影響は軽微なものから重大なものまで様々です。複数の種類のインジェクション攻撃はサーバに深刻な被害をもたらす可能性があり、通常、API自体が攻撃を実行するわけではなく、攻撃を他のシステムに伝える入り口となっています。注意すべき点は以下の通りです：

• SQLインジェクション
• HTMLインジェクション
• コードインジェクション
• コマンドインジェクション
• コンテンツインジェクション

2. クロスサイトスクリプティング（XSS）

XSSはクライアント側で実行されることが多いものの、格納型XSS攻撃に対しては、APIが第一線の防御となります。これにより、悪意ある者が危険な（しばしばJavaScriptの）コードを実行する恐れがあり、APIはこうした悪質な値を排除する役割を担っています。しかし、一つの見落としが大きな機会を与える可能性があります。

3. 分散型サービス妨害 (DDoS)

DDoS攻撃は、アプリ、システム、さらにはネットワーク全体を麻痺させる可能性があり、極めて破壊的です。DDoS攻撃は、システムが処理しきれない大量のリクエストを、複数の「ゾンビ」と呼ばれる感染したコンピュータが送信することで行われ、十分なトラフィックが発生すると、どんな堅牢なシステムでも容易に圧倒されます。

4. リソース不足とレート制限の不備

適切なレート制限が実施されていない場合、短時間に大量のデータ要求が行われ、システムに急激な負荷がかかります。これにより、攻撃者は従来よりも迅速にシステムを麻痺させる可能性があります。

5. 資産管理の不備

最も大きな脅威の一部は、把握されていない部分から生じます。多くの組織は、目に見える部分のセキュリティに重点を置く一方で、シャドウAPIを完全に見落としがちです。シャドウAPIとは、運用中でありながら誰にも知られていないAPIのことであり、適切な管理が行われず、新たな機能追加時に無視されるため、不正なデータアクセスや、さらにはリモートコード実行といった重大な問題を引き起こす可能性があります。

トップ10のベストプラクティス

これらを知ると多少不安になるかもしれませんが、以下のベストプラクティスを導入することで、セキュリティは大幅に向上します。

1. 強固な認証・認可ソリューションを使用する

不十分なAPIでは、利用者が実行する権限や認証が適切に確認されないことがあり、IDORやBACによるデータ漏洩などの重大な問題を引き起こします。APIは企業の貴重なデータへの入口となるため、誤った相手に情報を公開しないよう、特に注意が必要です。

2. セキュリティを優先する

現行予算にセキュリティが盛り込まれていないという意見も耳にしますが、実際のデータ漏洩にかかる費用は、適切なセキュリティ対策のコストを大きく上回る場合があります。システムの要件設計やコード作成時に、セキュリティを最優先に考慮することが大切です。

3. APIを把握し管理する

前述の通り、シャドウAPIは大きな問題です。これに対処するには、APIの在庫を正確に把握し、定期的に更新することが必要です。通信監視や未発見APIの列挙を自動ツールで行うのが最適です。

4. 最小権限の原則を実施する

最小権限の原則とは、APIに必要な権限だけを与えるという考え方です。これにより、万一APIが侵害された場合でも、被害はそのAPIの範囲内に留まり、システム全体への拡大を防げます。

5. TLSを使用して通信を暗号化する

TLSはトランスポートレイヤーセキュリティの略で、より馴染み深いSSLの後継です。これにより、フロントエンドとバックエンドAPI間の通信が安全に暗号化され、中間者攻撃のリスクを低減できます。

6. 共有すべきでない情報は削除する

API開発時には、ハッカーが狙う秘密情報が含まれる可能性があるため、APIセキュリティキー、ユーザ名、パスワードなどは必ず環境変数などの安全な保管場所に保存すべきです。この手順は見落とされがちであるため、自動化するのが効果的です。コード共有リポジトリにアップロードする前や、定期スキャンによって、情報の漏洩を防止する必要があります。

7. 必要以上のデータを公開しない

デバッグ目的でテスト環境において、必要以上のデータが公開されることがありますが、実運用前にはこれら余分な情報を必ず削除する必要があります。公開されるデータが少なければ、攻撃対象も減少します。

8. 入力値を検証する

本番環境で脆弱性が発生する主な理由は、入力値の検証やサニタイズが十分に行われていないことにあります。冗長な検証システムを常に用意し、前面システムだけに依存して無効な入力を遮断しないようにすべきです。倫理的ハッカーとして、XSSやCSTI以外では前面の検証に大きな期待は寄せません。攻撃対象はAPIであり、前面検証は利用者の誤入力を防ぐためのものです。

9. レート制限を使用する

バグ報奨制度で頻繁に報告されるこの問題は、ペネトレーションテストで見落とされがちです。不十分なレート制限、あるいは制限が全くないと、悪意ある者が大量のデータを要求したり、情報処理過多によりAPIへ過負荷をかけたりしてアプリが停止する恐れがあります。第三者サービスを利用している場合、リクエスト数に基づいて高額な料金が請求される可能性もあります。

10. Webアプリケーションファイアウォールを使用する

悪意ある利用者を防ぐ有効な手法のひとつは、WAFの導入です。これはウェブトラフィックの検査に特化し、規則に基づいて不正なリクエストを排除します。例えば、攻撃経路が含まれるリクエストを遮断します。ただし、WAFに全てを依存せず、前述の対策も併せて講じる必要があります。

‍

‍

2021年のベストプラクティス

フロントエンドデータと同様にバックエンドデータも守る

多くの組織はフロントエンドのセキュリティに注力しますが、バックエンドのデータがおろそかになることがあります。見える部分だけでなく、バックエンドシステムも守るため、冗長なチェック体制を整える必要があります。悪意ある者がフロントエンドを迂回し、直接APIにアクセスする可能性を考慮しなければなりません。

検証によるリクエスト・レスポンスライフサイクルの保護

攻撃者は、リクエストとレスポンスの不一致を狙うことがあります。例えば、レスポンスに含まれるフィールドがリクエストに存在しない場合、これをコピーして値を操作される危険があります。特に、isAdmin:falseをisAdmin:trueに変更するなど、重大な影響を及ぼすことが考えられるため、期待するボディやヘッダーが含まれないリクエストは厳格に拒否する必要があります。

パスワードをハッシュ化する

攻撃者がシステムに侵入した場合、利用者の本来のパスワードが知られることを防ぐため、パスワードはハッシュ化すべきです。さらに、ハッシュ前にソルトを追加することで、レインボーテーブルによる比較を防止できます。この手法は、API上のデータを守る上で非常に有効です。

APIのセキュリティテストを行いたい場合は、こちらの記事を参照ください： How to hack API

動画を見る：