A2B攻撃（App-to-Backend Attack） への対処を考える クラメソさっぽろIT勉強会 #16 ‧ 2026.11.10 ‧ いわさ 

⾃⼰紹介 2 

公表された事例（当事者の公式発表） 3 公表⽇‧業種 公式発表の内容（要約） 9/29 コンビニ アプリのサーバーを経由した不正アクセス 10/5 焼⾁チェーン 公式アプリの会員管理システムへの不正アクセス 10/8 コンビニ アプリに関連するシステムが不正に利⽤されたと 考えられる 10/30 公式アプリの管理システムへの不正アクセス ⽜丼チェーン 表は、公式発表の本⽂を確認できた例。 ※ どの発表も、A2B攻撃（公開アプリを解析してAPIを攻撃する⼿⼝）との関係は書いていない。 出典: 各社の公式発表（9/29〜10/30に公表） 

A2B攻撃（App-to-Backend Attack）の⼿⼝ アプリを⼊⼿‧解析 1 攻撃者 公開アプリ 2 4 ※NICTが確認したのは Androidアプリ。 iOSアプリやWebサービスの APIでも起こりうる バックエンド サーバー（API） 接続先‧キーを特定 3 APIを直接攻撃 1. アプリを⼊⼿して解析 2. 接続先と鍵を特定 3. サーバーごとに攻撃を変える 公開アプリのプログラムを調べ、 内部の情報を読み取る APIの接続先、パラメータ、 キーを⾒つける 個々のAPIの仕様に合わせて リクエストを送る 起こりうること 個⼈情報の漏えいや、サーバーへの不正アクセスにつながる可能性 NICTの定義 「攻撃者が⼀般に公開されているAndroidアプリを解析し、その解析結果を悪⽤して バックエンドサーバを攻撃する⼿法」を「A2B攻撃（App-to-Backend Attack）」と呼ぶ。 出典: JPCERT/CC 注意喚起 JPCERT-AT-2026-0030 II. ケースB（2026-10-08公開、10-23更新）∕ NICT CYNEX LETTICE「アプリ解析からのサーバ攻撃」2026-10-13（概要、A2B攻撃の概 要の節）∕ JPCERT/CC公式ブログ Eyes 2026-10-15 Appendix A（2026-11-06取得） 

APIの脆弱性と対策 

脆弱性の⼀覧 ● 認可の不備 他⼈のデータが取れる ● アプリに埋め込んだ鍵‧認証情報 取り出されて、正規アプリ以外からAPIを呼ばれる ● サーバー側の⼊⼒値の検証などの不備 SQLインジェクション、SSRF、RCEなどにつながる場合がある 出典: NICT CYNEX LETTICE 2026-10-13（A2B攻撃の概要、攻撃対象となっている主な脆弱性、推奨する対策の節） ∕ JPCERT/CC公式ブログ Eyes 2026-10-15 Appendix A（説明⽤の事例）（2026-11-06取得） 6 

脆弱性1：認可の不備 正常 攻撃者 アプリ 利⽤者Aでログイン 攻撃者 ⾃分（A）でログイン 7 GET /users/1001 ⾃分のID サーバー 本⼈のデータか確認 GET /users/1002 サーバー IDだけ書き換え ログインは確認 本⼈のデータかは未確認 Aの情報を返す Bの情報が返る 他⼈のデータ 認証は、利⽤者が誰かの確認。認可は、そのデータへの権限の確認。 IDOR（Insecure Direct Object Reference）: IDを指定するだけで、他⼈のデータを直接参照できてしまう不備。OWASPではBOLA （Broken Object Level Authorization）と呼ぶ。 ID（1001、1002）は説明⽤の架空の値。 出典: NICT CYNEX LETTICE 2026-10-13（攻撃対象となっている主な脆弱性、推奨する対策の節）∕ OWASP API Security Top 10 2023 API1（2026-11-06取得） 

脆弱性2：鍵‧認証情報の埋め込み 解析して 鍵を取り出す アプリ 全員に配布される 秘密鍵が埋め込まれている 8 攻撃者 解析して取り出した鍵で 署名を作る 署名つきで APIを直接呼ぶ サーバー 署名が正しいので 受け付ける アプリに埋め込んだ鍵は、⼊⼿した第三者が取り出せる JPCERT/CCのブログで、⼿⼝の説明に使われた事例。実際の攻撃で確認されたものではない。 出典: JPCERT/CC公式ブログ Eyes「連続不正アクセス事案の攻撃⼿法に関する調査」2026-10-15 Appendix A ∕ IETF RFC 8252 8.5節 ∕ OWASP API Security Top 10 2023 API2 （2026-11-06取得） 

脆弱性3：アプリ側だけの⼊⼒値検証 9 データベースを不正に操作される アプリ SQLインジェクション ⼊⼒チェックを アプリ側だけで実施 サーバー ⼊⼒値の検証が ⾜りない 内部システムにアクセスされる SSRF 攻撃者 アプリを通さない アプリを通さず APIを直接呼ぶ アプリ側のチェックだけでは、APIを直接呼ばれると迂回される。 説明⽤の例。SQLインジェクション、SSRF、RCEなどにつながる場合がある。 出典: NICT CYNEX LETTICE 2026-10-13（攻撃対象となっている主な脆弱性、推奨する対策の節）（2026-11-06取得） コマンドを実⾏される RCE 

対策の⼀覧 ● 対策1：呼ばれるたびに、サーバーが権限を確認する ● 対策2：鍵を埋め込まず、サーバー側で認証‧認可する ● 対策3：サーバー側で⼊⼒値を検証し、プレースホルダなどを使う ● 対策4：回数の上限、トークンの期限、保持する情報の削減で被害を抑える 出典: 対策1から4の各ページの出典欄に記載（2026-11-06、11-07取得） 10 

対策1：サーバー側での権限確認 11 ● ログイン中の利⽤者に、その操作とその データの権限があるかを、毎回サーバーで 確認する ログイン中の利⽤者 + データのID ● OWASPは、IDをランダムな値にすることも 勧めている（権限確認の代わりではない） サーバーが、毎回確認 ● 他⼈のIDで拒否されることをテストし、 通らない変更はリリースしない リクエスト この利⽤者に、この操作と このデータの権限があるか 権限あり データを返す 権限なし 拒否する 出典: OWASP API Security Top 10 2023 API1 How To Prevent ∕ NICT CYNEX LETTICE 2026-10-13（まとめの節）∕ 国家サイバー統括室「個⼈情報の漏えい等につながる不正アクセス への対策について」2026-11-05（2. 設計‧開発 (2) 対策例1）（2026-11-06取得） 

対策2：サーバー側での認証‧認可 1. APIの認証に使う秘密鍵や、有効期間の⻑い 認証情報を、アプリに埋め込まない 2. アプリ内の署名処理や難読化だけに 頼らず、サーバー側で 利⽤者を認証し、認可する 3. APIキーは、どのアプリかを⽰すもの。 利⽤者の認証には使わない 12 避ける: 鍵を埋め込む アプリ 秘密鍵を埋め込む API 署名が正しければ受け 付ける ⾏う: サーバー側で認証‧認可 アプリ 鍵を持たない サーバー 利⽤者を認証し、 操作ごとに認可 出典: JPCERT/CC公式ブログ Eyes「連続不正アクセス事案の攻撃⼿法に関する調査」2026-10-15 Appendix A（対策）∕ IETF RFC 8252 8.5節 ∕ OWASP API Security Top 10 2023 API2 （2026-11-06取得） 

対策3：サーバー側での⼊⼒値検証 SQLインジェクション SQL Injection SSRF Server-Side Request Forgery RCE Remote Code Execution SQL⽂の組み⽴ては、すべてプレースホルダで実装する 取得先を、可能な限り許可したところだけに限る。 リダイレクトは無効にし、取得した応答をそのまま返さない シェルを起動できる機能を使わない。 使うなら、引数を許可リストで検証する ⼊⼒値の検証は、サーバー側で⾏う。RCEの原因はOSコマンド実⾏だけではない（危険なデシリアライズなどは別の対策が必要） 出典: IPA（独⽴⾏政法⼈ 情報処理推進機構）「安全なウェブサイトの作り⽅」1.1‧1.2節、OWASP API Security Top 10 2023 API7（2026-11-07取得）∕ NICT CYNEX LETTICE 2026-10-13（推奨する対策の節）（2026-11-06取得） 13 

対策4：被害を抑える仕組み 14 回数の上限 トークンの期限 保持する情報の削減 APIの呼び出し回数に上限を トークンは適切な有効期限 保持する個⼈情報を減ら つけ、異常なリクエストを にして、⻑期間有効なトー し、攻撃されたときの被害 監視する クンを避ける を抑える 持つ情報を減らす例: ある焼⾁チェーンは、保持する個⼈情報を減らす新しいシステムへの変更を予定すると発表。 出典: JPCERT/CC 注意喚起 JPCERT-AT-2026-0030 III. 対策 ∕ 焼⾁チェーンの公式発表「公式アプリにおける今後のセキュリティおよび個⼈情報保護強化策について」（2026-11-06取得） 

まとめ 15 やってはいけないこと 忘れずにやること ● アプリ側のチェックだけに頼る ● 毎回、サーバーで権限を確認する ● 鍵や認証情報をアプリに埋め込む ● 認証‧認可を、サーバー側で⾏う ● ID指定のAPIで、権限確認を省く ● ⼊⼒値を、サーバー側で検証する ● APIキーを、利⽤者の認証に使う ● 被害を抑える対策も重ねる 出典: NICT CYNEX LETTICE 2026-10-13 ∕ JPCERT/CC 注意喚起 JPCERT-AT-2026-0030 ∕ IETF RFC 8252 ∕ OWASP API Security Top 10 2023（2026-11-06、11-07取得） 

No content