令和7年度 春期 情報処理安全確保支援士試験 午後 問3｜スマホアプリに埋め込まれた鍵が招いた写真流出——情報処理安全確保支援士で学ぶアプリ脆弱性とセキュリティ対策の実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 令和7年度 春期 情報処理安全確保支援士試験 午後 問3

• 主なテーマ: スマートフォンアプリの脆弱性、サーバ証明書の検証不備、ハードコードされた暗号鍵、クラウドストレージのアクセスキー保護、連番による不正ダウンロード、WebViewとURL検証、フィッシング対策

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

スマートフォンアプリは、私たちの生活に深く入り込んでいます。写真を注文する、買い物をする、ポイントを貯める——その裏側では、アプリとサーバ、そしてクラウドストレージが絶えず通信を交わしています。ところが、この「アプリの中身」は、PCのWebブラウザと違って利用者から見えにくく、開発者が安全だと思い込んだまま危険な作りが残ってしまうことが少なくありません。

情報処理安全確保支援士試験の令和7年度春期 午後 問3は、写真サービスのスマホアプリに潜んでいた複数の脆弱性を題材にした、いわば「アプリのセキュリティ総点検」のような事例です。サーバ証明書の検証を無視する作り、暗号鍵をアプリのコードに直接書き込んでいた設計、注文番号の連番、そしてアプリ内に表示するWebページ（WebView）のURL検証の甘さ——どれも現実のアプリ開発で起こりうる失敗ばかりです。

この記事では、こうした脆弱性がどのように連鎖し、全利用者の写真が流出しかねない事態を招いたのかを、一つのインシデント事例として読み解きます。アプリ開発に関わる方はもちろん、受験者がスマホアプリ特有の論点を整理する手がかりにもなるはずです。

インシデントの概要

舞台はA社。撮影機器の販売や写真のプリントサービスを全国200店舗で展開する、従業員2,000名の企業です。実店舗に加え、インターネットを介して撮影機器を販売するECサイト事業も持っていました。

このたびA社は、会員がスマートフォン（以下、スマホ）用アプリ（以下、Fアプリ）を通じて、写真入りのカレンダーなどのグッズ（以下、フォトグッズ）を注文できる新サービス（以下、Eサービス）を始めることになりました。Fアプリは、国内で広く使われている二つのスマホOS（OS-αとOS-β）の、過去5年以内にリリースされたバージョンをサポートします。

Eサービスの仕組みはこうです。Fアプリは、インターネットを介してA社のWebサーバ（FQDNは www.a-sha.co.jp）と通信し、写真は大手クラウドサービスプロバイダC社のクラウドストレージサービス（以下、Cサービス）にアップロードします。会員がフォトグッズを注文すると、A社Webサーバが注文を受け付けて注文番号を採番し、Fアプリは写真を「注文番号.zip」という名前でZIP圧縮してCサービスへ送る——そんな流れでした。

ログインすると会員には「認証トークン」（ログイン中であることを示す、推測困難な合言葉のような値）が払い出され、以後のリクエストでこのトークンを使って本人確認をします。また、キャンペーン案内のためにアプリ内にWebページを表示する機能もありました。

新サービスのリリース前、A社はセキュリティ専門会社のD社に依頼し、Fアプリの脆弱性診断を実施します。そして、その診断結果が、開発チームに冷や汗をかかせることになるのです。

何が起きたのか

D社の診断で見つかった脆弱性は、大きく三つでした。一つずつ、攻撃者の視点で何ができてしまうのかを追っていきましょう。

脆弱性1：サーバ証明書の検証エラーを無視していた

Fアプリは、HTTPS（通信を暗号化する仕組み）でサーバに接続する際、サーバ証明書（通信相手が本物であることを証明する電子的な身分証）の検証エラーが起きても、それを無視して通信を続けるようになっていました。

なぜこんな作りになったのか。開発チームのUさんが、診断結果報告会でその経緯を説明します。FアプリとA社Webサーバ間の通信内容に異常がないかを調べるため、開発用PCで通信解析ツール（通信を仲介して中身を見られるプロキシのようなツール）を使っていたところ、Fアプリでサーバ証明書の検証エラーが発生し、通信が止まってしまった。困ったUさんは、インターネット上の記事で「エラーが発生しても通信を続行する方法」を見つけ、それを参考にFアプリのコードを変更してしまった——いわば、開発時の都合で安全装置を外したまま出荷しかけていたのです。

この穴があると、攻撃者は中間者として通信に割り込み（偽のサーバ証明書を提示しても、アプリは文句を言わず通信を続けます）、暗号化されているはずの中身を盗み見られます。盗聴された内容には、Cサービスへのリクエストに含まれる「アクセスキー」（クラウドストレージのファイルを操作するための合言葉）とストレージ名が含まれていました。攻撃者は、AuthorizationヘッダーというHTTPの送信欄に書かれたアクセスキーを、そのまま取り出せてしまうのです。

脆弱性2：暗号鍵がアプリのコードに直接書かれていた

二つ目は、Cサービスのアクセスキーの守り方の不備です。A社は、アクセスキーを256ビットの共通鍵とAES-CBC（共通鍵暗号方式の一種）で暗号化し、Fアプリ内に保存していました。一見すると「暗号化しているから安全」に思えます。

しかし致命的だったのは、その暗号化に使う共通鍵と初期ベクトル（暗号化の最初に使う初期値）、そしてストレージ名までもが、Fアプリのコードの中に「定数」としてそのまま書き込まれていたことです。鍵を金庫にしまったのに、金庫の鍵を金庫の扉に貼り付けておくようなものです。

攻撃者がFアプリを解析（逆コンパイルなどで中身を読み解くこと）すれば、暗号化されたアクセスキーも、それを復号するための共通鍵も初期ベクトルもすべて手に入ります。あとはAES-CBCで復号するだけで、平文のアクセスキーが得られてしまう。「暗号化していた」という事実は、何の防御にもなっていなかったのです。

二つの脆弱性が連鎖して、全利用者の写真が危険に

ここで、脆弱性1と脆弱性2が恐ろしい形でつながります。どちらの経路をたどっても、攻撃者はCサービスの正規のアクセスキーを手に入れられる。そしてCサービスの仕様では、アクセスキーを使う方式（方式a）だと、そのキーに対応するストレージ内のすべてのファイルを操作できてしまいます。

さらに、ファイル名は「注文番号.zip」で、注文番号は00000001から始まる単純な連番でした。つまり攻撃者は、00000001、00000002……と順番に番号を増やしながらダウンロードを試行するだけで、Eサービスの全利用者の写真を芋づる式に抜き取れるのです。一人ひとりの写真は、知らないうちに他人の手に渡る——「自分の写真くらい」という油断が通じない事態でした。

脆弱性3：URL検証の甘さがフィッシングを招く

三つ目は、キャンペーン案内機能に関わる脆弱性です。A社は、会員に送るメールに「F-URL」という特別なリンクを含めていました。会員がメールからF-URLを開くとFアプリが起動し、アプリ内のWebView（アプリ画面の一部にWebページを表示するOSの仕組み）にキャンペーンページが表示されます。

このキャンペーンページからキャンペーンに応募するとき、会員のセッションを識別するために認証トークンが使われます。OS-αでは、表示されたキャンペーンページ上のコード（ECMAScript）が、Fアプリの `getToken` という関数を呼び出して認証トークンを受け取る仕組みでした。

当然、これを悪用されないよう、A社は対策を入れていました。`getToken` 関数の中で、呼び出し元のWebページのURLの先頭が「https://www.a-sha.co.jp」かどうかを確認し、そうでなければ空の文字列を返す——という処理です（図7）。一見、ちゃんとチェックしているように見えます。

ところが、この「先頭が一致するか」という検証（前方一致）に落とし穴がありました。F-URLのurlパラメータに細工したURLを仕込むことで、攻撃者のサイトへ誘導できてしまうのです。たとえば、攻撃者が `k-sha.co.jp` というドメインを取得していた場合、`https://www.a-sha.co.jp.k-sha.co.jp/` というURLを考えてみてください。これは「www.a-sha.co.jp」で始まっていますが、実際にアクセスするのは攻撃者の `k-sha.co.jp` というドメインのサブドメインです。同様に `https://www.a-sha.co.jp@k-sha.co.jp/` も、「@」の前はユーザー情報として扱われるため、本当の接続先は `k-sha.co.jp` です。

つまり、前方一致の検証は、こうした細工URLをすり抜けてしまう。攻撃者のフィッシングサイト（本物そっくりに見せかけた偽サイト）に誘導され、そこから認証トークンを盗まれるおそれがありました。しかもFアプリには、WebブラウザのようにアクセスしているURLを確認する手段がない。利用者は、自分が偽サイトを見せられていることに気づけないのです。

UさんとSさんは、図7の処理を直すだけでなく、そもそも偽サイトにアクセスできないようにする機能まで実装することにしました。A社は、検出された脆弱性をすべて修正したうえで、Eサービスの提供を開始しました。