APIの脆弱性はどの程度危険なのか、どうすれば攻撃を防げるのか：API実装の落とし穴に要注意

サイバーセキュリティツールベンダーのPortSwiggerは、APIの脆弱性対策について解説したブログ記事を公開し、警鐘を鳴らした。設計時からAPIの脆弱性に注意を払うこと、さらに攻撃者の立場でAPIをテストすることが重要だという。

[＠IT]

　サイバーセキュリティツール「Burp Suite」を手掛けるPortSwiggerは2021年1月4日（米国時間）、APIの危険性と対策について解説したブログ記事を公開した。

　APIに対する攻撃についての著書をNo Starch Pressから近く出版するコーリー・ボール（Corey Ball）氏へのマット・アトキンソン（Matt Atkinson）氏のインタビューに基づいた内容だ。ボール氏は、公認会計士事務所Moss Adamsのサイバーセキュリティコンサルティングマネジャーを務めている。ブログ記事の概要は次の通り。

APIセキュリティの現状

　APIは長年にわたって使われており、成熟したインフラだ。だが、攻撃者の関心は高まる一方だ。近年のマイクロサービスの台頭に伴い、APIエコシステムは複雑さを増しており、昔ながらのセキュリティ問題も相まって、極めて多くの脆弱（ぜいじゃく）性が残っているからだ。例えばオブジェクトレベルの権限認可の失敗やディレクトリトラバーサル、SQLインジェクション、盗難認証情報などの脆弱性だ。

　Gartnerは2017年12月時点で既に、APIの悪用は2022年までに、企業アプリケーションのデータ侵害を最も頻繁に引き起こす攻撃ベクトルになると予想していた。また、Akamaiは2018年10月に、API呼び出しだけでWebトラフィック全体の約83％を占めることを明らかにしている。2019年12月にはOWASP（Open Web Application Security Project）がAPIセキュリティだけをまとめた「API Security Top 10」を発表している。

API呼び出しの危険性はなぜ見落とされがちなのか

　セキュリティ評価の際にAPI呼び出しがよく見落とされることには理由がある。ボール氏の意見では、ほとんどのAPIは、主に開発者やマシンによって使用されるからだ。多くの企業は、システムで使われる全てのAPIを洗い出すのに苦労するだろうとボール氏は語っており、これが問題をさらに複雑にする。

　しかも、APIは多種多様であるため、スキャンしにくい。組織の中で見た目が似ているエンドポイントであっても、全く異なる仕様に基づいている可能性がある。

　ボール氏は、「多くの脆弱性スキャナーは、APIを適切にテストする機能が欠けており、APIの脆弱性検出を苦手としている」と指摘している。企業が実施するAPIセキュリティテストの内容が、脆弱性スキャナーを実行するだけだった場合、検出されなかったとしても、テスト結果が「偽陰性」の恐れがある。

　これは重大なセキュリティインシデントにつながりかねない。実際、2018年に米国郵政公社（USPS）では、あるアプリケーションに残っていたAPI実装の不備が原因で最大6000万人が影響を受けた可能性がある大規模インシデントが発生した。だが、その1カ月前に実施された脆弱性評価では、この問題を見つけることができなかった。

　USPSで起こったAPI実装の不備は、APIの設計時にセキュリティが考慮されていなかったことが原因だった。あるセキュリティ研究者はありふれた方法でこの不備を突いて、このアプリケーションのセキュリティを破ることに成功している。

現在のAPIはセキュリティを考慮した設計になっているのでは？

　APIは標準化が進んでおり、これは概して望ましいことだ。そのおかげで、テストの一部が容易になっていることは確かだ。だが、何かが標準化されているからといって、それが正しく実装されているとは限らない。組織はしばしば、そうした状況に陥ってしまう。

　APIを実装するときには多くの落とし穴がある。「定義に漏れがある」「アップデートされていない部分がある」「資産管理の問題から、以前のバージョンがまだ使えるようになっている」などだ。APIの実装時には、こうした問題を回避しなければならない。

APIのセキュリティ確保を目指す組織は何をすればよいのか

　APIのセキュリティ確保を目指す組織へのアドバイスを一つお願いしたところ、ボール氏の答えは、「APIをハックすること」だった。

　「極めて安全だと考えられるAPIを設計することはできる。だが、テストしなければ、サイバー犯罪者があなたの代わりに『テストする』だろう」（ボール氏）

　APIの脆弱性スキャンは良い出発点だが、それだけでは不十分だ。APIは、ビジネスロジックの重大な脆弱性が入り込みやすい場所であり、スキャナーが苦手とする部分だ。APIセキュリティに万全を期すには、既成の理論や概念にとらわれない水平思考や、侵入テストの場合と同じように「敵の立場で考える」ことが常に必要になる。

APIビジネスロジックの一般的な脆弱性とは何か

　ビジネスロジックの脆弱性は、「セキュリティを侵害する目的でアプリケーションに対して悪用可能な意図的に設計されたアプリケーション機能」と定義できる。

　アプリケーション機能について、プランニング時点で議論したとすると、一般にセキュリティよりもユーザーの利便性が優先されるだろうが、そこに問題がある。

　ボール氏は、サイバーセキュリティコンサルタントとしての経験から、脆弱性が生じた例を紹介した。同氏の以前の勤務先では、アプリケーション管理者が、アプリケーションユーザー全員のアカウント情報を簡単に検索できるようにしようとした。だが、この機能を保護することを考えていなかった。なぜなら平均的なユーザーはこの機能を発見したり、使ったりしないと想定したからだ。

　この事例の主な教訓はこうだ。真に効果的なサイバーセキュリティを確保するには、戦略レベルでセキュリティについて話し合う必要がある。サイバーセキュリティ担当者は、セキュリティを考慮した効果的な設計になるように、計画段階から意思決定の場に参加する必要がある。

　PortSwiggerは、APIセキュリティについて次のようにまとめている。「Webアプリケーションセキュリティの他のあらゆる側面と同様に、効果的なAPIセキュリティを確保するには、総合的なアプローチが必要になる。脆弱性スキャンから手動の侵入テストまで、あらゆる要素が含まれる。そして設計段階から、敵の立場で考えることを一定程度取り入れることが重要だ」