ウェブアプリケーションセキュリティ 第2版

第5章 API分析 API分析

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

APIエンドポイント分析 は、リコンツールキットの中で、サブドメイン発見の次に論理的なスキルである。このアプリケーションはどのドメインを利用しているのか？このアプリケーションが3つのドメイン(例えばx.domain、y.domain、z.domain)を持っている場合、それぞれのドメインが独自のAPIエンドポイントを持っている可能性があることに注意しなければならない。

一般化すると、サブドメインを発見しようとしたときと非常によく似たテクニックを使うことができる。ブルートフォースアタックや辞書攻撃はここでも有効だが、手作業や論理的分析もしばしば報われる。

APIを発見することは、サブドメインを発見することに続く、ウェブアプリケーションの構造について学ぶ2番目のステップである。このステップは、公開されたAPIの目的を理解し始めるために必要な情報を提供してくれる。APIがネットワーク上で公開されている理由を理解すれば、それがアプリケーションにどのように適合し、そのビジネス上の目的が何であるかを理解し始めることができる。

エンドポイントディスカバリー

前回 、今日のほとんどのエンタープライズ・アプリケーションがAPIの構造を定義する際、特定のスキームに従っていることを説明した。通常、APIはREST形式かSOAP形式のどちらかに従う。RESTはより一般的になりつつあり、今日のモダンなWebアプリケーションAPIの理想的な構造であると考えられている。

ブラウザの開発者ツールを使ってアプリケーションを操作し、ネットワークリクエストを分析することができる。もしこのようなHTTPリクエストがいくつもあれば、これはREST APIだと考えていいだろう：

GET api.mega-bank.com/users/1234
GET api.mega-bank.com/users/1234/payments
POST api.mega-bank.com/users/1234/payments

各エンドポイントは、関数ではなく特定のリソースを指定していることに注目してほしい。

さらに、ネストされたリソースpayments はユーザ1234 に属していると推測できる。これはこのAPIが階層的であることを示している。これは、このAPIが階層的であることを物語っている。

各リクエストで送信されるクッキーを見て、各リクエストのヘッダを見れば、RESTfulアーキテクチャの兆候も発見できるかもしれない：

POST /users/1234/payments HTTP/1.1
Host: api.mega-bank.com
Authorization: Bearer abc21323
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko)

リクエストのたびにトークンが送信されるのも、RESTful API設計の証だ。REST APIはステートレスであるべきであり、サーバはリクエスト元を追跡すべきではない。

これが本当にREST APIであることが分かれば、利用可能なエンドポイントに関して論理的な仮説を立て始めることができる。