最近、ペネトレーションテスト、Web脆弱性診断の案件でサーバレスの環境やAPIで構成されている環境が非常に多くなってきています。APIについては認証・認可に関連するクリティカルな脆弱性やバックエンドということで制御が甘く、不要な情報の出力や攻撃にヒントとなる情報が多く確認でき、制御回避することが容易な事例も多くあります。
SQLインジェクションやXSSのような脆弱性は開発者の間でもセキュリティ対策として意識されるように感じておりますが、APIに関しては対策がまだ緩いと感じております。
そこで、今回はOWASP API Security TOP 10を参考にセキュリティ強化のヒントとよくあるセキュリティ対策の抜けについて数回に分けて解説させていただければと思います。
少しでも参考になり、皆様のサイトのセキュリティが強化されることを願います。
今回は「API1:2019 – Broken Object Level Authorization」について解説します。
英語ではAPI1は以下の様に解説されています。
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
簡単に説明しますと、アクセスする機能レベルでユーザーの権限を確認しなさいということです。
あるユーザーが自分の購入しようとしているものを確認するため、以下の形式でAPIにアクセスしたとします。
/items/{user_id}/purchase/
もし、自分だけが参照できるページであり、きちんと制御しているAPIであれば、他のユーザーのuser_idに置き換えても表示されません。しかし脆弱なAPIはここに他のuser_idを入れることで表示できたり、また脆弱なアクセストークンでセッションが管理されている場合、アクセストークンを改竄して他のユーザーになりすまし、アクセスすることができます。脆弱なトークン管理については別の機会で解説します。
より脆弱なサイトではuser_idが推測しやすく、簡単に他のユーザーの情報が参照できてしまします。
今回は比較的分かりやすい例で解説しましたが、基本的には制御がしっかりなされていないと、ある法則を見つけて、その法則からAPIに送信するパラメータを操作することで非公開データが参照できることがあります。
このような脆弱性は入力値検証の不備による脆弱性ではないので、脆弱性スキャナーのような攻撃パケットで検査しても発見が難しいのが注意箇所になります。特に認証回避とかロジックの不備により制御回避のようなものは検査対象の機能を理解して裏のプログラムを想像しながら行わないと検出が難しい場合もあります。
最後に対策のまとめとしてポイントだけお伝えします。
きちんとユーザーレベルでアクセス制御するロジックを入れましょう！
APIの場合、アクセストークンで管理しているケースが多いのですが、そのアクセストークンからユーザーを特定し、そのユーザーが現在行うアクションが可能なのかというチェック機能です。
user_idなどオブジェクトを識別するようなIDはUUIDなどランダムに生成でき、推測が難しいIDを使いましょう！
連番などを採用しているIDはよく見られます。連番でも制御できているので問題ないと思えても、脆弱性が存在した場合は推測が難しいIDを採用することでかなりリスクが低減できます。 なお、OWASP API Security TOP 10にご興味がある方は英語サイトになりますが、以下のURLで参照できます。 https://owasp.org/www-project-api-security/