APIへの攻撃にWAFは有効か？
Akamaiの最新のGlobalトラフィックの観測では、Web攻撃総数のうち約3割がAPIに対して行われていることが明らかになった。もはやこれは、もう見過ごされたままで良い割合ではない。そこで、Webセキュリティの知見を提供するコミュニティであるOWASPがまとめた、API Security Top10という、Web APIの主なセキュリティリスクを挙げたランキングを見てほしい。
このリストの中には、クラウド型WAFで対策が可能な攻撃も含まれている。たとえば「API4：制限のないリソース消費」は、前回の記事で解説したレイヤ7 DoS（DDoS）の一種としてAPIサーバーやバックエンド処理の過負荷を引き起こして、サービスの機能停止につながる。そのほか、過剰なAPIリクエストに連動して外部サービス利用（たとえば多要素認証用のSMS送信や、空席照会など）の従量制課金がかさんでしまうなど、金銭的な被害に遭うリスクがある。
一方「API6：機密性の高いビジネスフローへの制限のないアクセス」は、APIリクエストを繰り返してデータベースに格納されている情報を過剰に読み出そうと、アクセスを繰り返したりする行為だ。これらのリスクには、WAFやAPI-GatewayでAPIリクエスト数のレート制御や、レスポンスするレコード数の制限ができれば対策が取れる。
また「API8：セキュリティの設定ミス」に含まれる、最新の脆弱性パッチが適用されていないプログラムを狙う攻撃に加え、2023年版のTop10ではランク外になってしまった SQLインジェクションや、ローカルファイルインクルージョン（LFI）、クロスサイトスクリプティング（XSS）などの比較的聞き馴染みのあるWeb攻撃も、APIリクエストの形式で依然として数多く試みられていることがAkamaiの最新調査で明らかになっているので、要注意だと言えるだろう。
これらのタイプのAPIへの攻撃は、リクエストのAPIフォーマットを識別した上で、WAFルールに照合可能な形に整える（パースする）能力を備えているWAFなら検知が可能だ。
API認証・認可に特有の攻撃 「BOLA」 とは？
さてここで、あらためてAPI Security Top10の上位を見てみよう。すると、認証・認可に関わる脅威が多いことがわかる。実は、APIを標的に絞った攻撃ではAPI認証・認可の脆弱性が真っ先に狙われる傾向がある。
その中でも最上位の「API1：オブジェクトレベルの認可の不備（BOLA: Broken Object Level Authorization）」はAPI認証・認可に特徴的な脆弱性であり、APIを使うサービスやアプリケーションで頻繁に生じている。BOLAは“本来アクセスが許可されるべきではないオブジェクトへ攻撃者がアクセスできてしまう”といった脆弱性だ。
次の図では、「システムがユーザーを判別するためにAPIリクエスト中で指定するユニークユーザーID (UUID) を不正に操作することで他人になりすまして認可を突破。本来アクセスできないオブジェクトにアクセスできてしまう」というBOLAの基本的な脆弱性の仕組みを示している。
不正に操作されたリクエストによってアクセスや操作ができるオブジェクトには個人情報や機密情報が含まれる可能性があるだけでなく、場合によってはIoTなどのデバイス制御を乗っ取られる可能性もある。
BOLAは、各社がそのサービス固有のAPIを開発する上でのシステム設計上における仕様の考慮不足や、実装上の見落としなどが原因で起きやすい。基本的な仕組みは単純に見えるため、「果たして開発時にそのような初歩的なミスが起きうるのか」と感じる人もいると思うので、実例を一つ取り上げてみたい。これはドイツ言語圏で使われている、「Scoolio（スクーリオ）」という学習支援アプリで明らかになった脆弱性だ。
本事例では、まず①にて、あるAPIエンドポイントにリクエストを送ると、②で同じ地域に住んでいる500名分のUUID付きのプロファイルのリストをレスポンスとしてスマートフォンアプリが受け取る仕様になっていた。UUIDはアプリの画面に直接表示されることはないが、細工したクライアントなら覗き見ることは簡単にできる。その後、入手したUUIDを③で別のAPIエンドポイントのパラメーターに含めることで、他のユーザーの個人情報や現在位置の情報などを入手することができた。
この例を見て、本職でプログラミングの経験のある方ほど「これは、ウチのアプリでも起こるかも…」と軽く青ざめるのではないだろうか。よく考えると、アプリを便利にするために良かれと思い実装した機能により、脆弱性が生じた原因ではないかと推測できる。恐らく地理的に近いユーザー間で学習の情報を交換するために、ユニークID付きで500人分のユーザーリストをアプリに返す仕様にしたのではないか。そしてそれを別の人が別の時期に書いたAPIの中で指定すると、一連の攻撃が成立することまで洞察ができなかったのだろう。
ある程度の規模以上の商用サービスでは、こうしたことが起きやすい。特にマイクロサービス化されたサービスではAPIエンドポイントを、何百、何千と持っている。さらに人気のサービスほど、便利な機能を持つ新しいアプリが日々開発されている。すると新機能に対応しようと、APIも毎日のように実装と更新が行われる。それにともない、新しい仕様やコードの中にスクーリオの例で挙げたような潜在的な脆弱性が日常的に生じていると考えられる。
