Confidential. For internal use only. APIセキュリティについて 知っておきたいこと 2023年11⽉ SR分科会 ISACA名古屋⽀部 調査研究・CISA教育担当 理事 ⻑⾕川達也 2023年11⽉18⽇（⼟） 14:00-14:50

はじめに • セキュリティリサーチ（SR）分科会へようこそ︕ • リサーチ報告で 広く浅くインプット • ⼿を動かすハンズオンで アウトプット＆エンジニアリング • ディスカッション（交流）で ⼈脈形成 ご都合よろしければ、15:00〜の ISACA名古屋⽀部 ⽉例会にもご参加ください

アジェンダ 1. 15分 リサーチ報告 • WebAPIの最新動向、OWASP API Security Top10 2023について 2. 20分 APIサーバーの⽋陥を探すハンズオン • パブリッククラウド (GCP) にて起動しているハンズオンAPIサーバーから簡単な⽋陥を探してもらう 3. 最⼤15分 ディスカッション(交流) • 最近使ってよかったWebAPIの話 • ボットからのアクセス、それGood︖, それBad︖の個⼈的⾒解

アジェンダ 1. 15分 リサーチ報告 • WebAPIの最新動向、OWASP API Security Top10 2023について 2. 20分 APIサーバーの⽋陥を探すハンズオン • パブリッククラウド (GCP) にて起動しているハンズオンAPIサーバーから簡単な⽋陥を探してもらう 3. 最⼤15分 ディスカッション(交流) • 最近使ってよかったWebAPIの話 • ボットからのアクセス、それGood︖, それBad︖の個⼈的⾒解

Confidential. For internal use only. WebAPIの最新動向 OWASP API Security Top10とは︖ WebAPIを有効活⽤しつつ、攻撃から守るには︖ ※本スライドで紹介するAPIは全てWeb APIです。次項以降はAPIと短縮表記しています。

APIベースのアプリケーションによる変化 近年のマイクロサービスの台頭に伴い、APIエコシステムは複雑さを増しており、極めて 多くの脆弱性や弱点が残っている(2021.5 PortSwigger社) APIベースのアプリでは、多くの処理がクライアントに移っている ⼀⽅で、SQLi / CSRF / パス操作のような従来の脆弱性は少なくなっている・・ しかし「APIならでは」の不備・⽋陥・弱点が明らかになっている 出典: https://owasp.org/www-pdf-archive/API_Security_Top_10_RC_-_Global_AppSec_AMS.pdf

APIの⽤語と基本設計 📗 RESTful API、GraphQL、(SOAP) ✅APIエンドポイント その機能APIの窓⼝ URLパス – 理解しやすいSearchエンドポイント名の例︓ https://FQDN/api/search – 要求されたデータ（リソース）やサーバー側での処理結果を返す 🪟公開API • 認証なし、誰でもリソースにアクセスできる 🔑⾮公開API • 認証あり • 認証後もユーザーによって返答するリソースを変えることも設計できる（認可） 絶対原則 ü 機密情報を公開APIで実装しないこと︕

認証と認可 認証 Authentication/AuthN • ユーザーの⾝元確認 • 知識/所有物/⽣体 • パスポート 認可 Authorization/AuthZ • 条件付きアクセス権限 • RBAC/ABAC/ACL • ビザ（査証）チケット Identity and Access Management (IAM) 運転免許証 認証によりユーザーの⾝元確認し、その属性によりアクセス権限を付与する、 認可チケットが認証されたユーザーに即紐づく⽅法がWebAPIでも主流

モダンなAPIキー（鍵）JSON Web Token (JWT) “ジョット”と呼ばれ、JSON形式のデータで署名による改ざんチェックを⾏います トークンの有効期限付きで、ステートレスな通信をサポート APIでの使い⽅の⼀例︓Authorization: Bearer ü BearerはOAuth2.0の仕様の⼀部 https://jwt.io Decode Debugger ☞ jwt.ioはクライアント側の JavaScriptで処理されサー バー側にトークンが送信され ないWebサービス ※ 他サービスにおいては、 貼り付ける際はJWTがサー バー側に送信されないかご注 意ください︕ 署名で利⽤するアルゴリズム データ実体 ユーザー識別⼦・有効期限 データが改竄されていないかの確認⽤

OWASP API Security Top10 • OWASP Top10のAPIベースのアプリケーション版 • API1~10にて設計および実装の不備、弱点あるあるを定義 • プロジェクト説明: https://owasp.org/www-project-api-security/ • 2019年版と2023年版 公式Doc: https://owasp.org/API-Security/ • 事前にRelease Candidate (RC)版を公開し、広く意⾒を受け⼊れ正式版となる • 最新版: 2023年2⽉RC公開 - 6⽉に正式版展開 • Webアプリ全般を対象にしたOWASP Top 10と類似もいくつかあるが、作成過程 が違う • OWASP Top 10は収集したデータを考慮して作成 • OWASP API Security Top 10 ではデータが不⼗分のため、公開されているバグバウン ティやニュースを収集し、APIセキュリティの専⾨家と議論して決めたもの

OWASP API Security Top10 番号 2023 英語名 2023 ⽇本語訳 API1 Broken Object Level Authorization オブジェクトレベルの認可の不備（BOLA） API2 Broken Authentication 認証の不備 API3 Broken Object Property Level Authorization オブジェクトプロパティレベルの認可の不備 API4 Unrestricted Resource Consumption 制限のないリソース消費 API5 Broken Function Level Authorization 機能レベルの認可不備（BFLA） API6 Unrestricted Access to Sensitive Business Flows 機密性の⾼いビジネスフローへの無制限のアク セス API7 Server Side Request Forgery サーバーサイドリクエストフォージェリ （SSRF） API8 Security Misconfiguration セキュリティの設定ミス API9 Improper Inventory Management 不適切なインベントリ管理 API10 Unsafe Consumption of APIs APIの安全でない使⽤

（参考）Top10⽐較 出典︓https://yamory.io/blog/owasp-api-security-2023/ API開発時には、OWASP Top 10を補⾜する形で OWASP API Security Top 10を活⽤する

API1:2023 オブジェクトレベルの認可の不備（BOLA) • リクエスト内のオブジェクト識別⼦を操作して、機密データへの不正アクセスを⾏う ことができる • 攻撃者は、識別⼦(ID)を変更するだけで、本来アクセスできないはずのオブジェクト （データ）に到達できる 例: id:153の⼈がid:154の⼈のデータを取得できてしまっている︕ 対策 ü ユーザーポリシーと階層構造に依存する適切な認可メカニズムの実装 ü idにGUIDのようなランダムで推測できないIDの利⽤ 実装 GET /user/154 {id:154,name: ⻑⾕川, Tel: 090…} id:153, name:名無し

API2:2023 認証の不備 • 認証が厳格に実装されていない場合、攻撃者がAPIユーザーになりすまし、機密データ に到達できる • ブルートフォース攻撃に対する保護がされていない • 未署名／弱い署名のJWTを受け⼊れてしまう、JWTの有効期限を検証していない 例: id:153の⼈がid:154の⼈の認証tokenを取得できてしまっている︕ 対策 ü 認証周りでは⾞輪の再発明をせずに、業界⽔準のスタンダードなものを利⽤する ü 認証を⾏うエンドポイントにはブルートフォース対策のメカニズムを導⼊する ü JWTは署名アルゴリズムを厳格にし、有効期限も検証する 実装 POST /token {alg:none}.{id:154} {id:154,name: ⻑⾕川, token: ey***********} id:153, name:名無し 通常 jwt {alg: HS256}.{id:153}

API3:2023 オブジェクトプロパティレベルの認可の不備 • 機密性が⾼いため攻撃者が読み取るべきではないオブジェクトのプロパティを露出 (API3:2019 Excessive Data Exposure) • 攻撃者がアクセスできないはずの機密性の⾼いオブジェクトのプロパティの値を変更、 追加、削除できる (API6:2019 Mass Assignment) Mass Assignmentの例: id:153の⼈が⾃分をadminに変更できてしまっている︕︕ 対策 ü オブジェクトを公開する時に、公開するオブジェクトのプロパティにユーザーがアクセスできる 必要があるかどうかを常に確認する ü 要件に従って返すプロパティを必要最⼩限にする ü クライアントが更新する必要があるオブジェクトのプロパティのみを変更できるように制限する 実装 POST /update {name:名無し,admin:true} {id:153,name:名無 し,admin=true} id:153, name:名無し admin: false

API4:2023 制限のないリソース消費 • 既定の時間内に受け取ることができるリクエストの数やサイズを制限していない • サービス拒否（DoS）攻撃に対して無防備 • サービスプロバイダからのリソース請求の増加 例:リクエスト数やサイズに制限がなく、サーバーリソースがパンパン︕ 対策 ü ⽂字列の最⼤⻑、配列内の要素の最⼤数、アップロードファイルの最⼤サイズなど、 受け取る全てのパラメータやペイロードの最⼤値を定義・適⽤する ü 定義された時間内でクライアントがAPIを実⾏できる頻度を制限するレート制限 （Rate Limit）を導⼊する ü 特に返すレコード数を制限するような処理に関しては、リクエストのパラメータを サーバーサイドで適切に検証する 設計 POST /upload POST /upload POST /upload

API5:2023 機能レベルの認可不備（BFLA) • APIエンドポイントやHTTPメソッドなどの実⾏制限を適切にできていない • API1 BOLA ☞ リソースオブジェクトへの認可の問題 • API5 BFLA ☞ 機能実⾏の認可の問題 例: 管理者しかできない(/admin/users/all)を⼀般の⼈が実⾏できてる︕ 対策 ü 各エンドポイントを機能レベルの認可の⽋陥がないかレビューする ü 管理機能がユーザーのグループ・ロールに基づいて認可制御されてい るか確認する 実装 GET /admin/users/all {users:[{id:1,name:…}, {id:2,name:…},{id:3,name:…}…. .]} id:153, name:名無し admin: false

API6:2023 機密性の⾼いビジネスフローへの 無制限のアクセス • ビジネスフローで予想されていない過剰なボットの処理により、機 密性の⾼い「購⼊・予約・招待・コメント」などで悪影響 例:ボットによる過剰な⾃動アクセスでクレジット（ポイント含む）を不正取得される︕ 対策 ü 過剰に利⽤された場合に悪影響があるビジネスフローを特定する ü デバイスフィンガープリント、CAPTCHAなどを利⽤し、⾃動化され たアクセスを防ぐ（悪意のあるボットかの判断の難易度⾼い︕） Credit: 100 pt 設計 Credit: 100 pt Credit: 100 pt Credit: 100 pt Credit: 100 pt Credit: 100 pt Credit: 100 pt Credit: 100 pt

API7:2023 サーバーサイドリクエストフォージェリ （SSRF) • URIをAPIサーバーが検証せずにリダイレクトしてリモートリソースを取得する攻撃⼿ 法・脆弱性 • URLパーサーライブラリの脆弱性に起因している • OSSやSaaSのよく知られたURLパスが攻撃を容易にする 例: バックエンドの169.254.169.254のサーバーから 意図せずtokenが取れてしまっている︕ 対策 ü 可能な限り許可リスト（想定されるリモートオリジン、URLスキーマとポート、コンテンツ タイプ）を使⽤する ü HTTPリダイレクトを無効化する ü URLパース⽅法の不⼀致を避けるために⼗分にテスト・保守されているURLパーサーを利⽤ する 実装 {token: ey***********} GET /statistics?url=http://169.254.169.254/ meta-data {token: ey***********} 169.254.269.254

API8:2023 セキュリティの設定ミス • 設定の漏れやミスによる適切なセキュリティ強化の⽋落 • FW設定/脆弱性パッチ/不要なロギング・エラーメッセージの有効化/TLSなし /CORSなし/Cache Controlなし 対策 ü 全ての環境における構成と設定の有効性を継続的に評価する⾃動化されたプ ロセスを導⼊する 実装 例: クラウドサービスで不適切なアクセス制御をしている︕ (リモートコード実⾏など)既知の脆弱性パッチが当たっていない︕ など、APIに限った話ではなく多岐に渡る

API9:2023 不適切なインベントリ管理 • 開発環境やベータ版など古いバージョンのAPIが公開状態で残存、 レート制限なし • 本番データが開発環境に⼊っている 例: ベータ版にレート制限が実装されておらず、総当たりでパスワードリセットが成功︕ 対策 ü API環境（本番、ステージング、テスト、開発）、ホストへネットワークアクセスできる⼈ （パブリック、内部、パートナー）、APIバージョンなどに関してドキュメント化する ü OpenAPIなどオープンスタンダードを採⽤し、ドキュメントの⾃動⽣成をする ü 本番環境以外のAPIで本番データを使⽤することを避ける 運⽤? POST /v1/password/reset POST /beta/password/reset POST /v1/password/reset POST /v1/password/reset POST /v1/password/reset {status:429, message: “too many, rate limit!”} POST /beta/password/reset POST /beta/password/reset POST /beta/password/reset {status:200, message: “success”} V1本番稼働 ベータ版

API10:2023 APIの安全でない使⽤ 3rd partyのAPIサーバーを利⽤する場合、受け取ったデータを検証せずに利⽤す ると情報漏洩やインジェクションの脆弱性を引き起こす 例: 3rd partyのAPIサーバーに登録したdrop db命令を 連携している⾃分のAPIサーバーが読み込んで実⾏してしまった︕ 対策 ü APIで受け取ったデータを使⽤する前に検証する ü レスポンスを処理するリソース制限・タイムアウト制限をする ü リダイレクトする可能性がある場合は許可リストを使⽤し、盲⽬的にリダイレクトしない ü APIの通信が安全な通信チャネル(TLS)上で⾏われていることを確認する 実装 ４ ⃣ { nam e: ‘; drop db; --’} １⃣ POST /register { name: ‘; drop db; --’} 3rd Party ２⃣ GET /service_list ３ ⃣ GET

APIを有効活⽤しつつ、攻撃から守るには︖ ✅APIサーバーも含めて脆弱性診断やシステム監査を⾏う ✅「OWASP API Security Top10」の対策セクション「How To Prevent」などを参考に設計時からセキュリティを導⼊する ⬅シフトレフト⬅ ✅漏れなく旧バージョンのサーバーやドキュメントの管理 （APIサーバーのドキュメンテーションは⾃動化できるので更新しやすい） ✅データ分析や脅威情報の収集によるAPI脅威ハンティング https://www.akamai.com/ja/glossary/what-is-api-threat-hunting

[参考]APIセキュリティツール⽐較 by TRACABLE社 (2022/03) すでにAPIセキュリティの監査・監視ツールが10社ほどあり、いくつかはふるまい解析によるボット軽減や詐欺の検出まで対応 出典: h$ps://www.traceable.ai/wp-content/uploads/2022/03/API-Security-Tool-Comparison-Guide.pdf

アジェンダ 1. 15分 リサーチ報告 • WebAPIの最新動向、OWASP API Security Top10 2023について 2. 20分 APIサーバーの⽋陥を探すハンズオン • パブリッククラウド (GCP) にて起動しているハンズオンAPIサーバーから簡単な⽋陥を探してもらう • 2分の事前説明 • 15分の演習時間 • 3分のデモ解説 3. 最⼤15分 ディスカッション(交流) • 最近使ってよかったWebAPIの話 • ボットからのアクセス、それGood︖, それBad︖の個⼈的⾒解

http(s)://[IPAddress]:[Port]/docs へブラウザでアクセス︕ ※[IPAddress]と[Port]は演習当⽇にSlackに書きます。

10個のAPIエンドポイントを⽤意しました 展開して 詳細を確認できます 鍵付きは 認証必要 /tokenは演習にて ⼿操作しません 各オブジェクトのス キーマはここを展開 してください

APIエンドポイントのSwagger UIでの実⾏⼿順 「Try It out」をクリッ クすると以下のように 展開される Request bodyを修正して下の「Execute」 をクリックし、APIエンドポイントへの curlアクセスを実⾏する

前座の詳説 [認証しJWTをブラウザに保存]のWeb UI⼿順 2.[認証ユーザー登録]に てご⾃⾝のユーザーを 作成してからクリック 解答やヒントを⾒たくない⽅はこのスライド以降は演習終了まで⾒ないこと usernameにメールアドレスを passwordにパスワードを⼊れ て他はそのままで Authorizeボタンをクリック エラーが出ずAuthorized となれば認証成功 ※Logoutを押さないか有効期限 の15分を超えない限り、鍵アイ コンのAPIエンドポイントも JWTトークンが渡った状態で利 ⽤できます 「Close」をクリックし閉じる

演習の解説は、講師の操作デモのみで⾏います これら３つのflag⽂字列を取得できましたか︖ ü hackeT{API5_Broken_Function_Level_Authorization} ü hackeT{API1_Broken_Object_Level_Authorization} ü hackeT{API3_Broken_Object_Property_Level_Authorization} 監査ヒント: L2FkbWluL3VzZXJfaWRzLwo= 監査ヒント: L3VzZXJzL3t1c2VyaWR9Cg== 監査ヒント: L3VzZXJzL3VwZGF0ZSAtPiAvYWRtaW4vZmxhZy8K

アジェンダ 1. 15分 リサーチ報告 • WebAPIの最新動向、OWASP API Security Top10 2023について 2. 20分 APIサーバーの⽋陥を探すハンズオン • パブリッククラウド (GCP) にて起動しているハンズオンAPIサーバーから簡単な⽋陥を探してもらう 3. 最⼤15分 ディスカッション(交流) • 最近使ってよかったWebAPIの話 • ボットからのアクセス、それGood︖, それBad︖の個⼈的⾒解

Confidential. For internal use only. ディスカッションテーマ 最近使ってよかったWebAPIの話 現地オフラインの⽅は、 3⼈程度のグループを作成し、議論してみてください。 Zoomオンラインの⽅は、Zoomチャットに書き込む形で交流してみましょう。 最後に発表やまとめは⾏う予定はありませんが、興味深いものは花⽥会⻑が紹介してくれるかも!? ボットからのアクセス、 それGood︖, それBad︖の個⼈的⾒解

No content