最近 API のセキュリティに関して勉強したのでちょっとメモみたいなやつ
皆さんこんにちは。
最近 "ハッキングAPI" という本を読んだのですよ。
API のセキュリティってあまり CTF でも見かけない（あまり参加できていないから目にしないだけかもしれないけれど......）から凄く新鮮で面白かったです。
そこで今回は OWASP API Security Top 10 に関してだらだらと書いていこうかと思います。
しかし、まだまだ勉強を始めたての身なので内容はかなり浅く、不正確な情報も多分に含まれると思います。
もし OWASP API Security Top 10 が気になったという方はぜひ本家のサイトに訪れていただけたらと思います。
サイトのリンクは下に貼っておきます。
OWASP API Security Top 10:OWASP API Security Top 10
2023年度の OWASP API Security Top 10 は以下の10個のようです。
- Broken Object Level Authorization (BOLA)
- Broken Authentication
- Broken Object Property Level Authorization
- Unrestricted Resource Consumption
- Broken Function Level Authorization
- Unrestricted Access to Sensitive Business Flows
- Server Side Request Forgery（SSRF）
- Security Misconfiguration
- Improper Inventory Management
- Unsafe Consumption of APIs
Broken Object Level Authorization (BOLA)
アクセス可能なユーザかどうかの検証がされること無く誰でもオブジェクトにアクセス出来る脆弱性みたいです。
AさんのデータにはAさん以外の人がアクセス出来てはいけないはずなのに、他の人がAさんのデータにアクセス出来てしまうような脆弱性みたいです。
この脆弱性の面白い部分なのですが、基本的にその API にアクセス出来るのは仕様という点ですね。
対策としてはレコードの ID に予測不可能な値を設定することや、認可の仕組みを実装することなどがあげられています。
Broken Authentication
認証の不備に関する脆弱性です。
API を使用できるユーザであるかを確認する機能が脆弱であった場合に、他人のアカウントを乗っ取ったりできてしまうかもしれないみたいです。
この脆弱性は API 仕様ではなく、API 側が提供している認証処理に脆弱性があるといったものみたいですね。
対策は認証処理に不備がないようにすれば良いのですが、言うは易く行うは難しです。
そもそも API はステートフルであることが前提であるため（REST API の6つの制約）、認証処理を実装するのはとても難しいと考えられます。（もしかしたら良い方法があるのかも知れないですが、あいにく分かりません......）
もっと冴えた素晴らしい技術が出てきたらそちらに変わったりするのかなぁ......とか考えたりします。
まぁ、技術がどのように進化していくかは予想できないですね。
Broken Object Property Level Authorization
ユーザが読み取るべきでないプロパティを公開していたり、ユーザがアクセス出来ないはずのプロパティの値を操作できてしまったりするような脆弱性みたいです。
CTF とかで出題しやすそうな脆弱性ですね。
対策としてはクライアントからの入力をそのまま入力値として適用しないようにすること（マスアサインメント脆弱性？）や、変更できるプロパティを制限すること、ユーザに返すプロパティを厳選することなどが挙げられています。
変なリクエストが来たときに余計な情報を渡してしまったり、値の変更がされないようにしましょう！という印象を受けました。
実際どうなんでしょうね？
Unrestricted Resource Consumption
リソースの使用量などに制限がかかっていないという脆弱性みたいです。
これに関しては API に限った話ではない気がしますね。
DoS 攻撃になったり、何かしら有料のシステムをしようしているのなら莫大な請求が引き起こされたりするのかも知れません。
対策としては制限を行えば良いのですが、多種多様な DoS 攻撃の手法を見た感じ一筋縄ではいかなそうですよね......
でも、制限を行えばいくつかの攻撃は防げるので対策は大事ですね。
Broken Function Level Authorization
異なるロールの API の機能を使用できてしまう様な脆弱性みたいです。
具体的には非特権ユーザが特権ユーザしか使うことが出来ない機能を使用できてしまったりするような脆弱性です。
ロールごとに API エンドポイントが分かれている場合以外にも、ロールごとに異なるHTTP リクエストメソッドを用いている場合もあります。（管理者は POST メソッドでユーザアカウントの作成が行える。一般ユーザは GET メソッドでユーザ自身の情報を取得できるといったようなもの？）
対策方法は、関数レベルでの認可をしっかりやることなどがあげられてますね。
他の対策はちょっと知識不足で理解ができてないですね......（コントローラがなんたらかんたらとか？）
Unrestricted Access to Sensitive Business Flows
商品の買い占めや予約の枠をすべて潰してしまうといったような脆弱性？みたいです。
こういうものも技術的な対策の範囲内なんですね。
てっきりそれらの企画の段階で不正が出来ないようにするものだと思っていました。（それらをしたうえでさらに技術的な対策が必要なのかも知れないですが）
Server Side Request Forgery（SSRF）
正直よく分かりません。
サーバの機能が実行できてしまうといった脆弱性なのでしょうか？
雰囲気的には与えられた URL にアクセスしてリクエストを取ってくるような機能のあるサーバに対し、本来アクセス出来無いような URL を与えると十分に検証されないことによってアクセス出来てしまったりするという感じなのかもしれません。（合っているかは分からないですね）
サーバの機能を悪用してるから SSRF なのでしょうか？
Security Misconfiguration
セキュリティの設定ミスに関する脆弱性みたいです。
凄く多岐にわたりますよね。
これに関しても API に限った話では無いと感じます。
Improper Inventory Management
古いバージョンが残っていたりするような脆弱性なのでしょうか？（いまいち全貌を把握できていない）
これも API に限った話ではないですね。
資産管理は重要です。
Unsafe Consumption of APIs
API からの入力を無条件に信頼してしまうことによる脆弱性みたいです。
どんな入力でもきちんと検証したほうがよいということなのでしょうか？
まとめ
だらだらと書きましたが、理解できてない点が多いですね。
もっと勉強しなければならないと思いました。
