OWASP API Security Top 10 2023〜OWASP Top 10との違い〜
OWASPよりOWASP API Security Top 10 2023 RCが現在公開されています。
OWASP API Security Top 10では、Web アプリケーションだけでなく、モバイルアプリ、IoTなど様々な用途で利用されているAPIのセキュリティリスクを理解し、対策するためのベストプラクティスとして提供されています。
今回は、OWASP API Security Top 10 2023の各項目の概要とOWASP Top 10との違い、活用方法、実際にどのような形で脆弱性が存在するのかをバグバウンティで公開されているものを例に紹介します。
（現在公開されているRC版を参考に記事を執筆しているため、正式リリース時の内容と異なる可能性があります）
OWASP API Security Top 10 2023
API1:2023 オブジェクトレベルの認可の不備（BOLA）
オブジェクトレベルの認可の不備（BOLA）は、攻撃者がリクエストで送信されるオブジェクトのIDを変更し、アクセスの許可がされていないオブジェクトへアクセスできてしまう脆弱性です。
この脆弱性により、情報の漏洩やデータの改ざんに繋がる恐れがあります。
オブジェクトレベルの認可の不備（BOLA）は、APIに最も多く存在する脆弱性と言われています。
対策
- ユーザーポリシーと階層構造に依存する適切な認可メカニズムの実装
- レコードのIDにGUIDのようなランダムで推測できないIDの利用
参考文献
API2:2023 認証の不備
認証の不備は、ブルートフォース攻撃に対する保護がされていない、未署名／弱い署名のJWTを受け入れてしまう、JWTの有効期限を検証していない、などがあります。
APIでの認証は、複雑で混乱しやすいメカニズムのため、脆弱性が発生しやすく、攻撃者から標的になりやすい部分です。
対策
- 認証周りでは車輪の再発明をせずに、標準のものを利用する
- メールアドレスの変更／電話番号の変更などの機密性の高い処理を行う場合は再認証を行う
- 認証を行うエンドポイントにはブルートフォース対策のメカニズムを導入する
- ユーザー認証にAPIキーを利用しない
参考文献
API3:2023 オブジェクトプロパティレベルの認可の不備
オブジェクトプロパティレベルの認可の不備は、オブジェクトへのアクセス時に、オブジェクトへのアクセス制限は行っている場合でも、そのオブジェクトの特定のプロパティへのアクセス制限を適切に行っていないことで発生する脆弱性です。
この脆弱性により、情報の漏洩やデータの改ざんに繋がる恐れがあります。
OWASP API Security Top 10 2019では、「API3:2019 - 過剰なデータ公開」「API6:2019 - 一括割り当て」として扱われています。
対策
- オブジェクトを公開する時に、公開するオブジェクトのプロパティにユーザーがアクセスできる必要があるかどうかを常に確認する
- クライアントが更新する必要があるオブジェクトのプロパティのみを変更できるように制限する
- 要件に従って返すプロパティを必要最小限にする
参考文献
API4:2023 制限のないリソース消費
制限のないリソース消費は、アップロードできるファイルサイズの制限やリクエストの数といったAPIリクエストによって消費されるネットワーク、CPU、メモリ、ストレージのリソースへの制限がされていない場合にサービス拒否（DoS）の影響やサービスプロバイダの請求の増加に繋がる恐れがあります。
対策
- 文字列の最大長、配列内の要素の最大数、アップロードファイルの最大サイズなど、受け取る全てのパラメータやペイロードの最大値を定義・適用する
- 定義された時間内でクライアントがAPIを実行できる頻度を制限するレート制限を導入する
- 特にレスポンスで返すレコード数を制限するような処理に関しては、リクエストのパラメータをサーバーサイドで適切に検証する
参考文献
API5:2023 機能レベルの認可不備（BFLA）
機能レベルの認可不備（BFLA）は、管理者しか実行できない機能を一般ユーザーが実行できてしまう、といった機能レベルのアクセス制限を適切にできていないことで発生する脆弱性です。
オブジェクトレベルの認可の不備（BOLA）と似た脆弱性ですが、リソースへのアクセスの認可の問題がBOLA、機能の実行の認可の問題が BFLAになります。
対策
- 認可制御のロジックを確認するために、各エンドポイントを機能レベルの認可の欠陥がないかレビューする
- 管理機能がユーザーのグループ・ロールに基づいて認可制御されているか確認する
参考文献
API6:2023 サーバーサイドリクエストフォージェリ（SSRF）
サーバーサイドリクエストフォージェリ（SSRF）は、外部から到達できない領域にあるサーバーなどに対して、バグを悪用することでリクエストを送る攻撃手法・脆弱性です。
APIがユーザー入力のURLを検証せずに利用する、ライブラリ間でURLをパースする仕組みが異なる場合に発生します。
対策
- 可能な限り許可リストを使用する
- HTTPリダイレクトを無効化する
- URLパース方法の不一致を避けるために十分にテスト・保守されているURLパーサーを利用する
参考文献
- URLの取り扱いには要注意！SSRFの攻撃と対策 - yamory Blog
- Server Side Request Forgery Prevention - OWASP Cheat Sheet Series
API7:2023 セキュリティの設定ミス
セキュリティの設定ミスは、クラウドサービスで不適切なアクセス制御がされている、最新のセキュリティパッチが適用されていない、不要な機能が有効になっているなど、様々なケースがあります。
対策
- 全ての環境における構成と設定の有効性を継続的に評価する自動化されたプロセスを導入する
参考文献
API8:2023 自動化された脅威からの保護の欠如
自動化された脅威からの保護の欠如は、攻撃者によって自動化された方法で過度に利用されることによって様々な形でビジネスに悪影響を及ぼす恐れがあります。
この脆弱性は、実装上のバグによるものではなく、自動化された脅威が考慮されていないことで発生します。
例としては、ユーザーを招待することでクレジットを得るサービスの場合、攻撃者によって大量の架空のユーザーを招待し、過剰なクレジットを得ることができる、というものがあります。
対策
- 過剰に利用された場合に悪影響があるビジネスフローを特定する
- デバイスフィンガープリント、CAPTCHAなどを利用し、自動化されたアクセスを防ぐ
参考文献
API9:2023 不適切なインベントリ管理
不適切なインベントリ管理は、提供しているAPIが適切に管理されていないため、古いバージョンのAPIやベータ版のAPIが存在し、悪用される恐れがあります。
例として、公式のAPIではレート制限がされているが、ベータ版のAPIにはレート制限がされていないために任意のユーザーのパスワードがリセットできてしまう問題が存在する、というものがあります。
対策
- APIホストのインベントリを作成し、API環境（本番、ステージング、テスト、開発）、ホストへネットワークアクセスできる人（パブリック、内部、パートナー）、APIバージョンなどに関してドキュメント化する
- オープンスタンダードを採用し、ドキュメントの自動生成をする
- 本番環境以外のAPIで本番データを使用することを避ける
API10:2023 APIの安全でない使用
APIの安全でない使用は、サードパーティAPIを利用する場合に受け取ったデータをユーザー入力よりも信頼し、検証せずに使用することで情報漏えいやインジェクションの脆弱性を引き起こす恐れがあります。
外部から提供されているAPIに関して、通信が暗号化されていない、受け取ったデータの検証がされていない、盲目的にリダイレクトしている、レスポンスを処理するリソース制限・タイムアウト制限をしていない、などの場合に脆弱性です。
対策
- APIの通信が暗号化されていることを確認する
- APIで受け取ったデータを使用する前に検証する
- リダイレクトする可能性がある場合は許可リストを使用し、盲目的にリダイレクトしない
参考文献
OWASP Top 10との違い
OWASP Top 10 2021とOWASP API Security Top 10 2023の項目を並べるとこのようになります。
OWASP Top 10
- 開発時だけでなく、設計、CI/CD、モニタリングと開発の幅広い工程を意識して作成されている
- APIでないWebアプリを含め、より幅広い開発スタイルを想定して作成されている
OWASP API Security Top 10
- 同じ認可の項目も細かく分割しAPIに特化した形で詳しく解説されている
- APIで特に起こりやすい自動化された攻撃、インベントリ管理、APIの安全でない使用が考慮されている
- より新しい開発環境を考慮したものになっているため、インジェクションはランク外になっている（※1）
また、Top 10の項目作りの手法に関しても違いがあり、OWASP Top 10は収集したデータを考慮して作成されていますが、OWASP API Security Top 10 2023ではデータの収集ができなかったために公開されているバグバウンティやニュースを収集し、APIセキュリティの専門家と議論して決めたものになっています。（※2）
上記のような違いからも、API開発者はOWASP API Security Top 10だけを見てセキュリティ対策をすれば良い、というものではないことがわかります。
API開発時に、OWASP Top 10を補足する形でOWASP API Security Top 10を活用することで、APIで起こりやすい脆弱性へ対処できます。
※1 https://github.com/OWASP/API-Security/issues/83#issuecomment-1458863746
※2 https://github.com/OWASP/API-Security/issues/77#issuecomment-1458713247
バグバウンティで報告された脆弱性
UberのAPIに存在したアカウント乗っ取りの脆弱性
UberのAPIには以下の2つの脆弱性が存在し、組み合わせることによってアカウント乗っ取りの脆弱性が存在しました。
1. 電話番号・メールアドレスを指定することでエラーメッセージからユーザーのUUIDの列挙が可能な脆弱性
以下のような電話番号・メールアドレスを指定したリクエストによってユーザーのUUIDを特定することが可能な脆弱性が存在しました。
POST /p3/fleet-manager/_rpc?rpc=addDriverV2 HTTP/1.1
Host: partners.uber.com
{"nationalPhoneNumber":"99999xxxxx","countryCode":"1"}
Response:
{"status":"failure","data":{"code":1009,"message":"Driver ‘47d063f8–0xx5e-xxxxx-b01a-xxxx’ not found"}}
POST /p3/fleet-manager/_rpc?rpc=addDriverV2 HTTP/1.1
Host: partners.uber.com
{"email":"xxx@gmail.com"}
Response:
{"status":"failure","data":{"code":1009,"message":"Driver ‘ca111b95–1111–4396-b907–83abxxx5f7371e’ not found"}}
エラーメッセージに不要なUUIDを表示されているため、これは「API3:2023 オブジェクトプロパティレベルの認可の不備」に該当する脆弱性だと考えられます。
電話番号やメールアドレスといった推測可能な、入手可能な情報からUUIDという推測が困難なものが特定されています。
UUIDが特定されただけであれば大きな問題ではないように思われますが、もう一つの脆弱性と組み合わせることによってアカウントの乗っ取りに繋げることができます。
2. ユーザーのUUIDを指定することでアクセストークンを含むユーザー情報の漏えいの脆弱性
以下のようなuserUuidに特定したUUIDを含めたリクエストによって、ユーザーのアクセストークンを含む全てのユーザー情報を入手できる脆弱性が存在しました。
POST /marketplace/_rpc?rpc=getConsentScreenDetails HTTP/1.1
Host: bonjour.uber.com
Connection: close
Content-Length: 67
Accept: application/json
Origin: https://bonjour.uber.com
x-csrf-token: xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36
DNT: 1
Content-Type: application/json
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: xxxxx
{"language":"en","userUuid":"xxxx–776–4xxxx1bd-861a-837xxx604ce"}
Response:
{"status":"success","data":{"data":{"language":"en","userUuid":"xxxxxx1e"},"getUser":{"uuid":"cxxxxxc5f7371e","firstname":"Maxxxx","lastname":"XXXX","email":"xxxx@gmail.com","token":"b8038ec4143bb4xxxxxx72d",
...
ユーザー本人だけがアクセス可能な情報にUUIDを指定するだけでアクセスできてしまっているため、「API1:2023 オブジェクトレベルの認可の不備（BOLA）」に該当する脆弱性だと言えます。
また、ユーザー本人からのアクセスであったとしても不要だと考えられるアクセストークンなどもレスポンスに含まれてしまっているため、「API3:2023 オブジェクトプロパティレベルの認可の不備」にも該当する脆弱性だと考えられます。
UUIDが推測困難なため、この脆弱性だけでは悪用には繋がりにくかったかもしれませんが、1つ目の脆弱性と組み合わせることによって、比較的容易にアカウント乗っ取りが行われる恐れがありました。
この脆弱性による報奨金 : $6,500
参考：How your Uber account could have been hacked!
Facebookのbeta APIに存在したアカウント乗っ取りの脆弱性
Facebookのパスワード再設定を行う場合、登録されている電話番号やメールアドレスに6桁の数字が送信され、その数字を入力することで再設定が可能でした。
6桁の数字の入力には、ブルートフォース攻撃への対策がされているため、10〜12回間違えるとブロックされるようになっていました。
しかし、beta.facebook.com、mbasic.beta.facebook.comというサブドメインに対してブルートフォースを行うとレート制限が正しく設定されていないため、ブロックされない脆弱性が存在しました。
そのため、以下のようなリクエストのnで指定される6桁の数字を変更しながら大量に送ることによって任意のパスワードに再設定することができ、アカウントの乗っ取りを行うことができました。
POST /recover/as/code/ HTTP/1.1
Host: beta.facebook.com
lsd=AVoywo13&n=XXXXXX
この脆弱性は、本番環境で利用することが想定されていないものが公開されている、本番データが利用されセキュリティの仕組みが本番環境とは異なる、といった「API9:2023 不適切なインベントリ管理」に該当する脆弱性です。
APIの場合は、古いバージョンのものも公開している、ドキュメントが更新されずに管理されていない場合にはこのような脆弱性が発生しやすいために特に注意が必要です。
この脆弱性による報奨金 : $15,000
おわりに
今回は、API開発時に気を付けるべき項目がまとめられているOWASP API Security Top 10 2023についてと、OWASP Top 10との違いやどのように活用するべきかについて解説しました。
加えて、OWASP API Security Top 10 2023の項目に該当する実際に世の中に存在した脆弱性について紹介しました。
自分たちの環境下でも同じような脆弱性が含まれていないか、確認する際の参考になればと思います。
OWASP Top 10だけではカバーできていないものや APIで特に注意が必要なものなどについて書かれていますのでAPIの開発、テストをする時にはぜひ利用していただければと思います。
yamoryでは、脆弱性診断サービスも提供しています。
興味がある方はこちらよりご確認ください。