「PCI DSS 4.0」のWebスキミング要件を読み解く
PCI DSS 4.0では、「JavaScriptを用いたWebスキミングへの対策」として、要件6.4.3と要件11.6.1が追加された。本稿では、要件6.4.3にフォーカスして詳しく読み解いていく。
要件6.4.3は、『消費者（サイト利用者）のブラウザに読み込まれ実行される、すべての決済ページスクリプトを管理すること』とされ、その目的は『消費者のブラウザでレンダリングされる決済ページに、未認可のコードが存在できない（ようにする）』と定義されている。前編で解説した実際のWebスキミングの仕組みとPCI DSSの用語集に照らし合わせると、これは、「決済ページ（と、消費者が認識しうるアカウントデータを入力するウェブベースのユーザーインタフェース）がブラウザに表示されたときに、想定外の動きをする未認可のコードがブラウザの中で動いていないように維持する仕組みを実装すること」を求めていると読み取れる。
[画像クリックで拡大]
ここでセキュリティ担当者が陥りやすい穴がある。それは、「決済ページのコンテンツの中で読み込んでいるスクリプトのコードは常に確認しているから、問題ないだろう」という思い込みだ。
実際の攻撃者は、サイトのホームページなど、利用者がサイト内をブラウズ中に通りそうな導線のどこかで、ブラウザに読み込ませる悪性のスクリプト（またはその一部）を仕掛けることが多い。読み込まれたスクリプトは一旦ブラウザの中で “潜伏” し、ページコンテンツに、「ショッピングカート」や「決済」に関連する文字が現れると、それまでブラウザの中で眠っていたプログラムが動き出して偽決済画面を表示したり、入力された文字を読み取ったりする。したがって、決済ページのコンテンツ内のコードだけを確認してもWebスキミングは防げない。さらに、セキュリティ監査などでの発見を避けるため、入力された文字を読みとる本体のコードを一定の条件が揃ってから外部サーバーから読み出し、その後自身を消去するものもある。このような攻撃の実態を踏まえれば、「サイト内のどこかで既に読み込まれ、利用者が決済に関わる行動を取った時点で動作しているスクリプトが想定外の動作をしないか管理する」仕組みが必要だと解釈すべきだろう。
[画像クリックで拡大]
また、要件6.4.3の運用上の注意事項には、『この要件は事業者の環境（ファーストパーティー）からロードされたすべてのスクリプトと、サードパーティーおよび第4の（フォース）パーティーからロードされるスクリプトに適用される』とある。
Webサイトで使われているスクリプトは、自身のサイト（ファーストパーティー）のスクリプトや、サイトが直接読み込みを指示しているサードパーティーサービスのスクリプトだけではない。そのサードパーティーのスクリプトにより、それ以外のサイトからブラウザに孫読み、ひ孫読み込みされている。この “スクリプトのサプライチェーン“ の末端に悪性のコードが潜んでいたとしても、Webスキミングは実行される。したがって、「予防するためにはサイトの管理者がすべてのコードを管理する必要がある」と注意事項で指摘しているわけだ。
これらのスクリプトは、サイトの新機能の実装やサードパーティーの仕様変更などで、管理者が知らないうちに変更される可能性がある。また、悪意がなくとも必要のない情報を読み取っているなど、許容できない行為をしていないかという点にも目を光らせて、管理していく仕組みが必須となるだろう。
