自社サービスのWeb API提供に潜むリスクとは　「OWASP API Security Top 10」から見る、脅威とその対策

登壇者の自己紹介とアジェンダの紹介

山根将司氏：「Web APIの提供メリットと、抑えるべきセキュリティリスク」と題して、私、株式会社ラックの山根が発表いたします。お願いいたします。

今回のアジェンダです。まずは、「Web APIって何？」という方向けに、Web APIの概要とその普及の背景を説明していきたいと思います。その次に、Web APIがどのように企業や組織に利益をもたらすかについて説明いたします。

続きまして、これが今回のメインのコンテンツとなりますが、Web APIを提供する上で抑えておきたいセキュリティリスクについてご紹介します。併せて、ラックで提供しているサービスについても紹介できればと考えています。

APIとは何か？

それでは、さっそく発表に進んでいきたいと思います。まず、Web APIの概要とその普及の背景について説明を始めていきます。

APIとは何かについて説明していきます。APIを一言で説明すると、このような文章になります。「Application Programming Interfaceは、開発者が複雑な機能をより簡単に作成できるよう、プログラミング言語から提供される構造です」。

ただ、この文章だと、いまいちピンと来ない方もいると思うので、今回、mdn web docsで紹介されているコンセントの例で紹介してみます。

（スライドを示して）これですね。あなたが家で機器を使いたい時には、電源コードのプラグをコンセントに差し込めば事足ります。電源に直接結線したりはしないでしょう。そんなのは非効率ですよ、ということですね。

APIを使うことで、コンセントにプラグを差し込むくらい簡単な操作で、複雑な機能を利用できるようになります。

今回は、Webサービスで用いられるAPI、すなわちWeb APIに焦点を当てて、説明をしていきたいと思います。

代表的なWeb APIの例

次に進みます。Web APIはこんなところで使われています。代表的な例を3つ紹介いたします。

まず1つ目。OpenAIのAPIです。現在すごく流行している「ChatGPT」ですが、こちらは、実はブラウザからでなくても、Web APIで使えます。APIサーバーにメッセージを投げることで、ChatGPTなどが生成した回答を取得できるという感じです。

2つ目が、「Google Maps API」です。このAPIを使うことで、作ったWebサイトに対して、「Googleマップ」の地図を埋め込むことができます。こちらは、けっこういろいろなサイトで使われているので、目にしたことがある方も多いのではないかと思います。

3つ目が「Stripe API」。こちらは、決済サービスのAPIです。決済サービスを最初から作ろうとすると、すごくハードルが高く、もしかすると脆弱性を作り込んでしまうかもしれません。そこで、こういったAPIを使うことで、問題を解決することができます。

Web API普及の背景は「開発の効率化」と「外部サービスとの連携」

次に進みます。続いて、Web API普及の背景です。総務省が出している「平成30年版　情報通信白書」では、（スライドを示して）このような記述があります。Web APIが普及した理由は、このように2つ挙げられています。

1つ目が、開発の効率化です。このように、APIサーバーを作っておくことで、例えば、内部でWebアプリとスマホアプリの両方を開発する際に、共通している処理を共通化することができます。これで、それぞれのクライアント実装時の手間を省くことができます。

2つ目が、外部サービスとの連携です。作ったAPIサーバーを外部に公開しておくと、外部のサーバーから、このAPIを使ってもらえるのでサービスの連携が容易になります。

複数の要素を組み合わせて新しいものを作る「マッシュアップ」も適用できる

次に進みます。もう1つ大事な要素があって、マッシュアップですね。マッシュアップというのは、複数の要素を組み合わせて新しいものを作ることですが、こちらはWeb APIにも適用できます。

この例では、Googleマップのような地図アプリのAPIと、「食べログ」のような、レビューサイトのAPIを組み合わせることによって、近場のレストランを表示するアプリを作ることができます。

地図上にレストランの場所を表示したり、近場のレストランの評価を一目で確認できる機能を付けることができます。このマッシュアップも、APIが普及した一因であると考えています。

企業がWeb APIの利用で得られるメリットとは？

それでは、次のテーマに入っていきます。次に、企業がWeb APIを利用するメリットについて考えていきたいと思います。

まず、なんといっても、開発者コミュニティの拡大という大きなメリットがあります。これは現在流行中のOpenAIでもそうなのですが、Web APIを公開することで、それをさまざまな人に使ってもらって開発をしてもらうということができます。

それにより、APIを使うコミュニティを形成することができて、そこからさらに、APIの利用例を提供したり、開発者間が気軽に交流できるようなフォーラムを公開したりすると、形成されたコミュニティをどんどん拡大することができます。

では、次に進みます。もう1つメリットがあります。マルチデバイスやクロスプラットフォームにおける開発の効率化ですね。APIでは、基本的に、JSONやXMLといった形式でデータ形式が統一されています。

1回JSON形式のAPI基盤を作っておくことで、こちらのAPIの処理は共通して使えるので、それぞれのクライアント側、例えばPCやスマートフォンでは、JSON側の加工処理にだけ注力すればよいということになります。このように、さまざまなデバイスにおける開発の効率化が可能です。

Webアプリケーションセキュリティに関する10大脅威を示した「OWASP Top 10」

次に進みます。ようやく本題のセキュリティの話に入っていければと思います。

まず、WebアプリケーションセキュリティのオンラインコミュニティであるOWASP（Open Worldwide Application Security Project ）が、作成した「OWASP API Security Top 10」について、紹介したいと思います。

OWASPといえば、Webアプリケーションセキュリティに関する10大脅威を示した「OWASP Top 10」で広く知られていると思いますが、（スライドを示して）この図は、それのAPI版です。ここに「2023」と書いてあるとおりですね、2023年に更新されたばかりのものです。

この項目をすべて説明しようとすると、少し時間が足りなくなってしまうので、今回は、このAPI3、「オブジェクトプロパティレベルの認可の不備」と、API4、「制限のないリソース消費」と、API9、「不適切なインベントリ管理」の3つを簡単に紹介できればと考えています。

「データが過剰に公開される」「権限のないデータの更新が可能になる」API3の事例と対策を紹介

それでは次に進みます。API3、「Broken Object Property Level Authorization」がどういった問題かを一言で説明すると、サービス利用者が本来閲覧可能でない情報を閲覧できてしまったり、権限のない情報の更新が可能になってしまったりするという問題で、大きく分けて2つの問題点があります。

1つ目が、データが過剰に公開されてしまうという問題です。こちらは情報漏洩にもつながってしまいます。これは、例えば、IDを指定して、他人のユーザー名を取得するというAPIを作った時に、そのAPIの応答にユーザー名だけでなく、住所や電話番号といった、センシティブな情報が含まれてしまっていたというようなケースが該当します。

2つ目の、一括割り当て。これは、マスアサインメントとも言いますが、APIが受け取ったデータのチェックが不十分なまま、そのデータベースに割り当ててしまうことです。こちらは、権限のないデータを更新されてしまうおそれがあります。

この脆弱性は、とある有名なサービスでも見つかっていて、SSH（Secure Shell）の公開鍵を勝手に登録できてしまったという問題が見つかり、議論が発生したという経緯があります。

続きまして、事例の紹介に入っていきます。こちらは、「X」、まぁ、「Twitter」ですね……Twitterとの連携が可能な質問アプリでもこの脆弱性が見つかっています。

例えば、ユーザー情報を返すAPIがあったのですが、そのレスポンスに、ユーザー情報に加えてしまって、そのユーザーのアクセストークンが含まれてしまったというものです。

このアクセストークンが取られてしまうと、そのユーザーになりすますことができてしまうので、攻撃者はそのアクセストークンを使って、メールアドレスを取得したり、Xへ書き込みをしたりということができてしまったという問題です。

この問題の対策を、3つ紹介します。まず1つ目は、APIの要件を決めておくということです。APIを設計する際に、このAPIの入力と出力をどうするかを事前に相談しておくというところですね。これが1つ目です。

2つ目は、必要なデータのみを取得して、それをAPIのレスポンスに渡す、ですね。こちらのユーザー情報を返すAPIでもそうですが、「このAPIで使う情報にアクセストークンって必要だっけ？」というのをしっかりと考えた上で、必要な情報のみAPIのレスポンスに渡すのが重要です。

3つ目ですね。フレームワーク側でアクセス制限を設定することもできます。これで、API3の紹介は終わりです。

「サービス利用者がAPIを通してリソースを過剰に消費できてしまう」API4の事例と対策を紹介

続きまして、API4ですね。「Unrestricted Resource Consumption」、制限のないリソース消費なんですが、こちらの問題は、サービス利用者がAPIを通してリソースを過剰に消費できてしまうという問題です。

これは、Web APIを提供することで、そのサービスが使いやすくなるというメリットはあるのですが、一方で、負荷の大きい処理を大量に実行されてしまうというリスクが生じます。

どういったリスクがあるのかというと、例えば、大量アクセスによってCPUのリソースが枯渇してしまって、サービスが停止してしまうとか、大容量のファイルアップロードを何回も実行されてしまって、ストレージが枯渇して、サービスの停止につながってしまうとか。

SMS認証って、実行ごとに課金が発生するのですが、これを何回も実行されてしまった結果、サービスにかけられる金額を超過してしまう問題であったり、あと、APIに「認証する」という機能があったとすれば、ワンタイムパスワードの総当たりをされてしまって、その認証が突破されてしまうことも考えられます。

次に進みます。事例としては、実は弊社ではこの脆弱性がありました。APIを「AWS Lambda」で実装していたのですが、そこで無限ループが発生してしまい、特に実行回数の制限を付けていなかったので、300万円以上請求されてしまったというケースです。

一応こちらは社内のAPIだったので、それほど重大なインシデントにはつながらず一安心でしたが、外部に公開するAPIでは、こういったセキュリティに気を配る必要が出てきます。

この問題に対する対策は、この表にまとめています。CPU、メモリ、ストレージ、ネットワーク、それぞれに対応した制限方法を取ることもできますし、根本的な対策として、APIの回数制限を設定することも有効かなと考えています。

情報漏洩のリスクが潜む「野良API」

では次に進みます。もう1つ、野良APIについても紹介したいと思います。これは、先ほどのOWASP Top 10における不適切なインベントリ管理に該当します。シャドウAPIという言い方もします。

これは、機密情報を取り扱うAPIサーバーが、誤って外部に公開されてしまっていたといったケースを指していて、情報漏洩のリスクにつながってしまうリスクがあります。

なので、例えば社員が勝手にAPIサーバーを構築して、それが公開されていないか、もう使われていない古いAPIサーバーが残っていないか、というのを企業側で監視や管理するためのルール作りが必要です。

せっかくこの部分のセキュリティをガチガチに固めていても、1ヶ所、こういった野良APIが存在して穴ができてしまうと、その企業全体のセキュリティのレベルをそのまま下げてしまいます。

ラックにおけるAPI診断サービス

それでは次に進みます。ラックのサービス紹介を少しさせてください。

ラックでも、先ほど紹介したAPIの診断は対応していて、通常の脆弱性診断で、Webサイトと同様にAPIの診断を実施できます。

先ほど紹介したOWASP API Security Top 10でいうと、例えばこのAPI1の「Broken Object Level Authorization」だったり、API7の「Server Side Request Forgery」といった問題点を検出することができます。

通常の脆弱性診断メニュー以外にも、「Web API診断サービス」というのがあって、こちらでは、認証・認可を重点的にチェックすることができます。

APIを使う際に、認証と認可をきちんと付けようとすると、OAuthやOIDCを使うことになるのですが、そういった機能がきちんと実装できているかというのを、チェックできます。それ以外の独自実装のシングルサインオンにも対応できます。

OWASP API Security Top 10を網羅して検査したいという要望もあるとは思いますが、この表を見ると、一部通常の脆弱性診断ではどうしても見つけにくいような問題があります。

例えば、（スライドを示して）この、不適切なインベントリ管理ですね。この問題をきちんとチェックするためには、やはり内部からきちんと調べる必要があります。そういった問題については、個別対応というかたちを取らせていただいています。

API診断の中で見つけた変わった脆弱性

それでは次に進みます。私は、普段から、APIの診断をしているのですが、診断をしている中で、けっこう変わった脆弱性が見つかることがあるので、今回はそれを1つ紹介したいと思います。

（スライドを示して）このようなAPIがありました。パラメーターが2つですね。トークンとフォーマットの2つのパラメーターがあって、これを実行すると、ユーザーの設定情報がレスポンスとして返ってくるというものでした。

一見普通のAPIなのですが、ここで、形式をクライアント側が指定しているのがすごく気になり、例えばこれをJSONではなくHTMLとかにしたらどうなるんでしょうかということで、試してみました。

するとなんと、レスポンスがJSONからHTMLで返ってきました。これだけなら別に問題はありませんが、この返ってきた画面が、通常の画面ではなくて管理画面だったんですよね。なので、自身の情報だけではなく、他ユーザーの情報も確認できてしまったという、少し変わった脆弱性が見つかりました。

ホワイトペーパーの紹介

では最後に、Web APIセキュリティに興味を持った方へということで、現在、ラックではAPIセキュリティに関するホワイトペーパーを公開しています。（スライドを示して）こちらのQRコードからダウンロードできるので、興味がある方は、ダウンロードしていただければと思います。

今回紹介したAPI特有の脆弱性などについて、より詳細に解説しているので、ぜひ見てみてください。いったんラックとしての発表はこれで終わりです。

既存のソリューションで対策できないAPI特有の脆弱性を解決できる「API Security」

続いて、Akamaiさんの製品である「API Security」について、簡単に紹介させてください。私自身は、この製品にあまり詳しくないので、製品に関する質問がありましたら、Akamaiさんのブースに担当者さんがいるので、そちらにお願いいたします。

このAPI Securityは、WAFやAPI Gatewayなどの既存のソリューションでは対策ができないような、API特有の脆弱性を解決できる独自の仕組みを備えています。

API攻撃は、WAFやAPI Gatewayでは防ぎきれません。基本的にAPIの通信には、外部とのやり取りをするものがあるのですが、実はこういった通信だけではなくて、アプリケーションが大規模になるほど、APIのやり取りは、自組織内のアプリケーション同士が行う通信が大半を占めるようになってきています。

従来の対策であるWAFやAPI Gatewayだと、境界型の防御としては有効ですが、いったんこの内側に入られてしまうと、それを検知や制御することが難しくなります。