令和6年度 秋期 情報処理安全確保支援士試験 午後 問3｜カード非保持化でも漏れたクレジットカード情報

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

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

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

• 主なテーマ: Webスキミング、格納型クロスサイトスクリプティング（XSS）、クレジットカード情報漏えい、ECサイトのファイル改ざん、トークン型決済による非保持化、委託先管理

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

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

「うちはカード情報をサーバに保存していないから安全だ」——ECサイトを運営する多くの企業が、そう考えています。決済代行会社のトークン型決済を導入し、クレジットカード情報をサーバに残さない「非保持化」を実現していれば、もし侵入されてもカード情報は盗まれない、というのが一般的な理解です。

ところが、令和6年度 秋期の情報処理安全確保支援士試験 午後 問3が描くのは、まさにその「非保持化していたはずなのにカード情報が漏れた」という逆説的なインシデントです。鍵を握るのは、近年クレジットカード情報の漏えい原因として急増している「Webスキミング」という攻撃手法でした。

この記事では、情報処理安全確保支援士試験の過去問を題材に、ECサイトで実際に起こりうるセキュリティインシデントとして事例を再構成します。受験者にとっては設問の答えにたどり着く考え方を、経営者・管理職にとっては「決済代行に任せても残るリスク」を理解する材料になるはずです。

インシデントの概要

舞台となるのは、インテリアを扱うECサイトを運営する従業員200名のJ社です。J社のECサイト（以下、J社ECサイト）は、利用者が商品をブラウザで選んで購入できる、ごく一般的なオンラインショップでした。

システムは、Webアプリケーションプログラム（以下、WebアプリP。Webサイトの動きを担うプログラム本体）、利用者からのアクセスを受けるWebサーバ、そしてデータを保管するDBサーバ（データベースサーバ）で構成されていました。J社はこれらの開発や運用を自社で抱え込まず、WebアプリPの開発・保守と、Webサーバ・DBサーバの構築・管理・保守をV社という委託先に任せていました。

支払方法はクレジットカード決済と銀行振込の二つ。注目すべきは、クレジットカード決済の仕組みです。J社はD社の決済代行サービスを利用し、D社が提供する決済用ECMAScriptプログラム（ブラウザ上で動くJavaScript系のプログラム）を使ったトークン型決済を導入していました。これは、カード番号などの生のカード情報をJ社のサーバに保存せず、決済に必要な「トークン」と呼ばれる引換券のような値だけを扱う方式で、クレジットカード情報の「非保持化」を実現するものです。

つまりJ社は、クレジットカード業界が推奨する「カード情報を持たない」体制を、きちんと整えていたのです。それでもなお、利用者のカード情報は攻撃者の手に渡ってしまいました。なぜそんなことが起きたのか——ここからが本題です。

何が起きたのか

最初の異変は、利用者からの問合せという形でやってきました。

6月11日から12日にかけて、複数の利用者から似たような声が届きます。「クレジットカード情報を入力する画面が2回表示される」「支払方法を選んでいないのに、勝手にクレジットカード決済になってしまう」。J社ECサイト担当者のGさんは、この2つの訴えに引っかかりを覚えました。

J社ECサイトの購入の流れは、ショッピングカート（/cart）→ 配送先・支払方法選択（/shopping）→ 支払手続（/payment）→ 注文完了（/confirm）という4つの画面で進みます。本来、クレジットカード番号や有効期限、名義、セキュリティコードを入力する欄が現れるのは、最後のほうの「支払手続」画面だけのはずです。それなのに「2回表示される」とは、どういうことか。

Gさんは、ある仮説に行き着きます。誰かが偽のクレジットカード情報入力フォーム（以下、偽フォーム）を表示させているのではないか——。彼はこの懸念を上司のRさんに報告したうえで、6月11日分のWebサーバのアクセスログ（誰がいつ、どのページにアクセスしたかの記録）を洗い始めました。

ログから不審なアクセスを抜き出すと、いくつもの「攻撃の足あと」が浮かび上がってきます。あるアクセスでは、ログイン画面のパラメータに `'UNION select 1 FROM…` という、データベースへの不正な問い合わせを試みる文字列が混ざっていました。別のアクセスでは、ショッピングカートに商品を追加するパラメータに `"><script>` という、HTMLを途中で抜け出してプログラムを埋め込もうとする文字列が含まれていました。

しかし、Rさんが最も引っかかったのは別の1行でした。`PUT /ec-j/layout/js/customize.js` ——PUTというメソッド（サーバ上のファイルを新しい内容で書き込む操作）で、`customize.js` というファイルが更新されていたのです。Webサーバのファイル更新は、本来V社が事前申請をしたうえでSSH（暗号化された遠隔操作の通信）で接続して行う運用のはず。Rさんは、この更新が本当にV社の作業なのかをV社へ至急確認するよう、Gさんに指示しました。

数日後、V社からの回答で全容が見えてきます。問題のPUTによる更新は、V社の作業ではありませんでした。調べると、Webサーバに置かれていたECMAScriptファイルの一つ `customize.js` が、攻撃者の用意したファイル（以下、ファイルK）にまるごと置き換えられていたのです。

この `customize.js` は、ふだんは中身が空のファイルで、Webサイトのデザインを一時的に変えたいときに使うためのものでした。やっかいなことに、WebアプリPの仕様上、`customize.js` の読み込みを無効にすることはできません。つまり、利用者が配送先・支払方法選択画面を開くたびに、攻撃者が仕込んだファイルKが必ずブラウザで実行される状態になっていたのです。

ファイルKがしたことは巧妙でした。配送先・支払方法選択画面には、本来「クレジットカード決済」「銀行振込」を選ぶラジオボタン（どれか一つを選ぶ丸いボタン）が並んでいます。ファイルKは、このラジオボタン部分のHTMLを書き換え、そこに「カード番号」「有効期限」「名義」「セキュリティコード」を入力させる偽フォームを差し込みました。同時に、支払方法を内部的に「クレジットカード決済」に固定する細工も加えていました。

利用者から見れば、配送先を選ぶ画面で、いつのまにかカード情報を入力させられている格好です。そして「次へ」ボタンを押した瞬間——ファイルKに仕込まれた処理が裏で動き出します。利用者が入力したカード番号やセキュリティコードを集め、攻撃者のWebサーバ `i-sha.com` へこっそり送信していたのです。

恐ろしいのは、利用者がこの異変にほとんど気づけないことです。「次へ」を押すと、画面はそのまま本来の支払手続へ進んでいきます。本物のカード情報入力フォームがもう一度現れるので、利用者は「あれ、さっきも入力したのに」と戸惑いながらも、もう一度入力して購入を完了してしまう。最初の「カード情報を盗む偽フォーム」と、2回目の「正規の決済フォーム」——これが利用者の言っていた「2回表示される」の正体でした。

このように、ECサイトの画面に不正なスクリプトを忍ばせ、利用者が入力したカード情報を横取りする攻撃を「Webスキミング」と呼びます。サーバにカード情報を保存していなくても、利用者がブラウザに入力する「その瞬間」を狙うため、非保持化をすり抜けてしまうのです。本件に関する利用者からの問合せは、最終的に合計32件にのぼりました。