情報処理安全確保支援士 2024年 秋期 午後 問03

　 　J社は、インテリアを扱うECサイト（以下、J社のECサイトをJ社ECサイトという）を運営する、従業員200名の会社である。 　 〔J社ECサイトの構成〕 　J社ECサイトは、Webアプリケーションプログラム（以下、J社ECサイトのWebアプリケーションプログラムをWebアプリPという）、Webサーバ及びDBサーバで構成されている。J社はWebアプリPの開発及び保守、並びにWebサーバ及びDBサーバの構築、管理及び保守をV社に委託している。WebアプリPのアプリケーションログには、アクセス日時、画面名、アカウント名、アクセス元IPアドレスなどが記録される。 　J社ECサイトでの支払方法は、クレジットカード決済及び銀行振込に対応している。 　クレジットカード決済はD社の決済代行サービスを利用している。D社の提供する決済用ECMAScriptプログラムを使用したトークン型決済を用いて、クレジットカード情報の非保持化を実現している。商品購入に関する画面の概要を表1に、画面遷移を図1に示す。

〔利用者からの問合せ〕 　6月11日から12日にかけて、複数の利用者から、クレジットカード情報を入力する画面が2回表示されるという問合せ、及び支払方法が勝手にクレジットカード決済になってしまうという問合せがあった。J社ECサイト担当者のGさんは、偽のクレジットカード情報入力フォーム（以下、偽フォームという）が表示された可能性があると考え、上司のRさんに報告した上で、Webサーバの6月11日のアクセスログに不審な点がないかどうかを確認した。Webサーバの6月11日のアクセスログのうち、不審と思われるアクセスを抽出したものを表2に示す。

　次は、アクセスログに関するRさんとGさんの会話である。

　Rさん：偽フォームの表示が可能な攻撃の痕跡はあったのか。 　Gさん：表2のa行目がb脆弱性を狙った攻撃だと思いますが、そういった攻撃であれば偽フォームの表示が可能です。さらにb脆弱性がc型であれば、1回の攻撃で多数の利用者に対して偽フォームの表示が可能です。 　Rさん：それとは別に、表2のd行目はe脆弱性を狙った攻撃の痕跡だと思うが、仮にその脆弱性が存在した場合に、偽フォームの表示は可能なのか。 　Gさん：WebアプリPが、DBサーバに格納している情報を基にWebページを動的に生成していれば可能かもしれません。 　Rさん：承知した。その他、表2の10行目のPUTメソッドでファイルが更新されている点も気になる。以前、セキュリティベンダーに依頼して報告を受けているWebアプリPの脆弱性診断レポートに、b脆弱性及びe脆弱性の指摘があるかどうかと、PUTメソッドによる更新はV社によるものかどうか、V社に至急確認してほしい。

　Gさんは、6月13日にV社に問い合わせた。また、最新バージョンのWebアプリPに対する脆弱性診断レポートを確認したところ、脆弱性の指摘はなかった。 　 〔偽フォーム表示の原因の調査と対策〕 　6月14日にV社から連絡があり、PUTメソッドによるファイル更新はV社によるものではなかったことが判明した。Webサーバに設置していたECMAScriptファイルの一つcustomize.jsが攻撃者のファイル（以下、ファイルKという）に置き換えられていた。customize.jsは、通常時は空のファイルであり、Webサイトのデザインを一時的に変更する際に利用するものである。①配送先・支払方法選択画面でファイルKが読み込まれており、HTMLの一部が書き換えられていた。この書換えによって、②配送先・支払方法選択画面から支払手続画面への画面遷移の処理で利用しているパラメータの値が変更され、支払方法がクレジットカード決済に固定されていた。ファイルKを整形したものを図2に、配送先・支払方法選択画面のHTMLソースを図3に示す。

　その後、6月16日にV社から、customize.jsの置換えについての調査結果及び対処の報告があった。その報告を図4に示す。

〔クレジットカード情報の漏えいの調査と対策〕 　本件に関する利用者からの問合せは、6月15日21時45分が最後であり、合計32件あった。次は、customize.jsの置換えによる影響の調査に関するRさんとGさんの会話である。 　 　Rさん：クレジットカード情報入力フォームが2回表示されたのは、customize.jsが置き換えられていた影響で偽フォームが表示されたからだったのか。 　Gさん：そのとおりです。2回目に表示されたクレジットカード情報入力フォームにクレジットカード情報を入力し、送信している場合だけ、当社で注文が完了していました。 　Rさん：ダミーのクレジットカード情報を設定して図2でGETリクエストが送られる先のURLにアクセスしたところ、404のステータスコードが返ってきた。もし、攻撃者のWebサーバが適切なステータスコードを返しているとしたら、この結果から、攻撃者のWebサーバにWebアプリケーションプログラムが用意されておらず、クレジットカード情報は盗まれていないと判断してよいか。 　Gさん：③利用者が改ざんされた画面に入力して、クレジットカード情報が送信されてしまったときに、攻撃者のWebサーバでWebアプリケーションプログラムを用意していなくても、攻撃者は利用者の入力したクレジットカード情報を取得する方法があります。クレジットカード情報は盗まれたと判断すべきです。 　Rさん：クレジットカード情報の漏えいの可能性について利用者に案内を出したい。攻撃者のWebサーバにクレジットカード情報を送信した利用者を特定してほしい。攻撃者のWebサーバに情報を送信してしまった利用者は漏れなく特定したいが、送信していない利用者はできるだけ含めたくない。そのためには、どのようにすればよいのか。 　Gさん：V社の報告から、customize.jsの置換えの影響のあった期間は6月11日13時12分から6月16日9時00分と考えられます。攻撃者のWebサーバにクレジットカード情報を送信する直前までの操作をした利用者を被害者候補として特定するために、その期間のアプリケーションログからfを抽出したいと思います。 　Rさん：それで抽出してくれ。 　 　その後、Gさんは、プロキシサーバなどのキャッシュの影響も考慮した上で、被害者候補を特定し、その情報を基に案内を出した。また、J社は、関係当局に報告、届出を行うとともに、V社と協力して再発防止策を検討し、実施した。さらに、Webサーバのファイルの改ざん検知の検討を行うことにした。