What is Mobile Application Security Testing

スマホアプリのセキュリティ診断とは

スマホアプリ診断の対象

スマホアプリ診断は、Android・iOSアプリの本体と、アプリが通信するバックエンドAPIを対象にするセキュリティ診断です。アプリとサーバの両方について、攻撃に悪用される不備がないかを確認します。

アプリ本体では、通信の暗号化、認証情報の扱い、端末内のデータの保存を確認し、デバッグ機能が有効のまま残っていないかも調べます。APIでは、認可の不備、入力値検証の不足、エラー処理の問題を検証します。Webアプリケーション診断もAPIを対象にしますが、スマホアプリ診断では、端末に配布されるアプリ本体も解析の対象にします。

公開アプリから読み取れる情報

アプリストアで一般公開しているスマホアプリは誰でも入手でき、解析の手段も広く知られています。難読化ツールを使っても、解析を完全に防ぐことはできません。ビルド済みのアプリには、接続先サーバのURLや、APIを呼び出すためのリクエストの組み立て方が含まれています。攻撃者はそこから、事業者が公開していないAPIの仕様を読み取れます。

そのため、スマホアプリを公開する事業者は、接続先サーバやAPIの仕様が攻撃者に知られることを想定して、サーバを設計・運用する必要があります。

NICTが特定したA2B攻撃

国立研究開発法人情報通信研究機構(NICT)の脅威情報分析チームLETTICEは、2026年10月13日、国内で相次ぐ情報漏えい事案の原因の一つとして、一般に公開されているAndroidアプリを解析し、その情報を悪用して接続先のバックエンドサーバを攻撃する手法を特定したと注意喚起を公表しました。LETTICEはこの手法を「A2B攻撃(App-to-Backend Attack)」と名付けています。

A2B攻撃では、攻撃者が公開アプリを入手・解析し、アプリが通信するサーバの接続先やAPIの仕様を調べます。そのうえで、調べた仕様に合わせてサーバを攻撃します。サーバの認証・認可や入力値の検証に不備があれば、アプリ自体に脆弱性がなくても、不正アクセスや個人情報の漏えいにつながるおそれがあります。

アプリ解析を起点としたバックエンドサーバ攻撃の流れ公開アプリの解析ストアから誰でも入手可能難読化していても解析は可能情報の抽出接続先サーバのURLAPIの仕様・パラメータバックエンド攻撃調べた仕様に合わせてサーバを攻撃公開していないサーバの内部仕様が攻撃者に知られるサーバに不備があれば、情報漏えいにつながるおそれ対策: 解析されることを想定して、アプリ本体とAPIの両方を診断する
NICT注意喚起(2026年10月)で特定された「A2B攻撃」の流れ。公開アプリからは、攻撃者がバックエンドサーバの接続先やAPIの仕様を読み取れます。

AIによる解析の効率化と攻撃の広がり

NICTは、AIの活用によってアプリの解析や脆弱性の発見が効率化され、こうした攻撃がより多くのシステムに広がる可能性があると指摘しています。アプリを解析して攻撃手順を組み立てるには、これまで相応のスキルと時間が必要でした。AIでこの工程の一部を自動化できれば、攻撃者は少ない手間で多くのアプリを解析できるようになります。

NICTは、同様の問題がAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも起こり得るとして、これらを提供する事業者にも注意を促しています。

NICTが推奨する事業者の対策

NICTは注意喚起の中で、Androidアプリを公開する事業者に3つの対策を推奨しています。「侵害の確認」では、公開APIやサーバを洗い出し、アクセスログから不審なアクセスがないかを調べます。「脆弱性の点検」では、APIの認可不備(IDOR/BOLA)、SSRF、RCE、SQLインジェクションなどを点検します。「暫定的な緩和策」には、不要なAPIの停止やアクセス制限などがあります。またNICTはプレスリリースで、個々のシステムの診断や改修には専門的な確認が必要だとして、セキュリティ専門事業者などへの相談を呼びかけています。

コクチョウのスマホアプリ診断は、このうち「脆弱性の点検」にあたります。診断では、攻撃者と同じ手順でアプリを解析してAPIの仕様を把握し、その情報をもとにサーバ側を検証します。攻撃者より先に弱点を見つけられれば、悪用される前に修正できます。

アプリ本体の診断

アプリ本体は、ストア配布版または検証用ビルドを対象に診断します。逆コンパイル・逆アセンブルでコードを調べる静的解析と、実機でアプリを動かしながら観察する動的解析を組み合わせて、攻撃者がアプリから読み取れる情報と、アプリ内でのデータの扱いを確認します。

1

ストレージとデータ保護

アプリが端末内に保存するデータの暗号化、認証トークンの保存方法、バックアップ経由でのデータ漏えいリスクを確認します。ログイン情報や個人情報を平文で保存していないかを検証します。

2

通信の保護

平文のHTTP通信が残っていないか、サーバ証明書の検証を緩める実装がないかを確認します。診断では、信頼していない証明書を提示するプロキシを挟み、アプリが接続を拒否するかで中間者攻撃(MITM)への耐性を検証します。証明書ピンニング(受け入れる証明書を限定する対策)を導入している場合は、その動作も確認します。

3

認証とセッション管理

セッショントークンについて、ログイン時に新しく発行されるか、有効期限が適切に設定されているか、ログアウト時にサーバ側で無効になるかを検証します。生体認証など、端末内で行う認証を回避できないかも確認します。

4

リバースエンジニアリング耐性

リリース版のアプリでデバッグ機能が無効になっているかを確認します。root化端末・脱獄端末の検知、コードの難読化、改ざんの検知といった解析対策を導入している場合は、その実装状況も診断します。これらは解析の手間を増やす対策であり、必要かどうかは業種やアプリの性質によって異なります。

バックエンドAPIの診断

APIは、Webアプリケーション診断と同じ観点で診断します。攻撃者はアプリを解析すればAPIの接続先やパラメータを把握できるため、APIの仕様を公開していないことは対策になりません。そこで、仕様が攻撃者に知られた状態でも安全かを検証します。

1

認可の検証

ログイン中のユーザーが他のユーザーのデータにアクセスできないか(IDOR/BOLAと呼ばれる認可不備)、一般ユーザーが管理者向けの機能を使えないかを検証します。管理者向けAPIは、アプリの画面に機能がなくてもコード内に呼び出し先が残っていることがあるため、解析で見つかったAPIを一般ユーザーの権限で呼び出せるかを試します。

2

入力値検証と業務ロジック

アプリ側で入力を制限していても、通信を改変すれば任意の値を送れます。そのため、サーバ側にSQLインジェクション、RCE(サーバ上で任意のプログラムを実行される脆弱性)、SSRF(内部ネットワークなどへサーバからリクエストを送らせる脆弱性)がないかを検証します。金額や数量の改ざん、手順を飛ばした状態遷移といった業務ロジックの不備も対象です。

3

情報漏えい

攻撃者は自分の端末でアプリの通信内容を確認できるため、画面に表示されない項目でも、レスポンスに含まれていれば読み取れます。エラーメッセージに内部構造を示す情報が含まれていないか、レスポンスに他ユーザーの個人情報などの不要な項目が含まれていないかを確認します。

業種・用途ごとの確認(金融・ゲーム・規制業種)

金融、ゲーム、規制業種のアプリでは、共通の観点に加えて、業種ごとに想定される不正の手口を検証します。金融やゲームでは金銭や資産の不正な操作、規制業種では法令で保護が求められる情報への不正アクセスが主な対象です。

1

金融系アプリの不正操作対策の確認

資金を扱う操作について、送金・決済の金額や送金先の改変、残高や審査状態の改ざん、認証の回避ができないかを検証します。正規のリクエストを再送するリプレイ攻撃や、同時送信で残高確認をすり抜ける競合状態(レースコンディション)の悪用も試します。いずれも、サーバ側で検証しているかを確認します。

2

ゲーム系アプリのチート対策確認

通信の改変による報酬・所持金・アイテムの不正付与、端末側の判定を悪用した勝敗の操作、自動化ツール(Bot)による不正プレイを検証します。改造されたアプリ(改造APK・改変IPA)の検知を導入している場合は、その動作も確認します。報酬や勝敗など結果に影響する判定をサーバ側で行っているかが主な確認点です。

3

規制業種のアプリ(医療・行政・交通など)

マイナンバーなど法令で保護水準が定められた情報を扱うアプリや、交通・MaaSのアプリが対象です。アプリ経由のアクセスに対する認可や、重要な操作がサーバ側で記録されているかを確認します。確認したい基準があれば、ヒアリングのうえ診断観点に反映します。

OWASP MASVS・Mobile Top 10への対応

コクチョウのスマホアプリ診断は、OWASP(Open Worldwide Application Security Project)が公開するモバイルアプリのセキュリティ検証標準(MASVS)とOWASP Mobile Top 10をもとに診断項目を設計しています。そのうえで、A2B攻撃のようにアプリの解析を起点とする攻撃を想定し、解析で得たAPIの情報を使ってサーバ側を検証する項目を加えています。

診断の流れ

工程内容
事前ヒアリングアプリの概要、対応OS・バージョン、利用しているバックエンドAPIの範囲に加えて、証明書ピンニングや解析対策など、導入済みのセキュリティ対策の有無も伺います。
ご提案アプリの規模とAPIの数を踏まえて、診断範囲と期間をご提案します。
診断の実施アプリ本体の解析とAPIの診断を並行して進めます。テスト環境または本番環境の検証用アカウントを利用します。
報告書の作成発見された脆弱性について、再現手順と影響、対策を報告書にまとめます。
再診断修正後の再診断を実施し、対策の効果を確認します。

必要なもの

1

検証用のアプリとテストアカウント

診断には、検証用のアプリ(ストア配布版または検証用ビルド)と、テスト用のアカウントが必要です。

2

APIの仕様書

APIの仕様書があれば、あわせてご提供ください。診断の観点を整理する材料にします。

3

ソースコード

ソースコードがなくても、アプリを解析するブラックボックス診断で診断できます。ソースコードをご提供いただければ、コードを読んで確認するホワイトボックス診断を組み合わせ、解析だけでは見つけにくい実装上の問題も調べられます。開示が可能な場合は、ご提供をお願いしています。

まとめ

公開しているスマホアプリからは、攻撃者がバックエンドサーバの接続先やAPIの仕様を読み取れます。解析そのものは防げないため、解析されることを想定してアプリ本体とAPIの両方を診断し、見つかった弱点を修正しておくことが、情報漏えいのリスクを減らします。

コクチョウでは、Android・iOSアプリとバックエンドAPIをあわせて診断する「スマートフォンアプリケーション診断」を提供しています。AI脆弱性診断と組み合わせることもできます。

よくあるご質問

Aいいえ。難読化は解析の手間を増やす対策であり、解析そのものを防ぐことはできません。ビルド済みのアプリには、接続先サーバのURLやAPIの呼び出し方が含まれています。アプリを公開している以上、解析されることを想定して、サーバ側の設計と診断を進めることをおすすめします。

診断の相談はこちら

スマホアプリとAPIの診断を検討されている方は、まずはお気軽にご相談ください。