CheckoutHelperのv3で何が変わり、どう安全になったのか

この夏にWebPayでインターンをしている @toriimiyukki です。

インターン中にセキュリティの調査やテストなどを行い、その成果としてCheckoutHelperのv3をリリースしました。

これまでのCheckoutHelperは、カード情報入力フォームを動的にDOMを生成しページに埋め込んでいましたが、iframeでページに埋め込むよう変更し、ユーザーが直接webpay.jpドメイン内のフォームにカード情報を入力することができるようになりました。

しかし、このバージョンアップではiframeを使えない環境などに依存があるため、既存のCheckoutHelperのv2を更新せず、新たにv3としてリリースをしています。

何が変わったのか

これまでのCheckoutHelperは、JavaScriptが読み込まれたページ内にカード情報入力フォームのDOMを生成する仕組みでした。

しかし、この方式では以下の問題があり、今回のバージョンアップで解決されています。

  • CheckoutHelperが利用するスタイルシートのクラス名などが重複し得る
  • CheckoutHelperを読み込んだページからカード情報のDOMを参照できてしまう

前者は導入時点に概ね見た目からも気づくことができ、比較的大きな問題ではありませんでしたが、v3より元のページのスタイルの影響を受けないようになったため、v2まで意図してスタイルシートを適用している場合には無効となります。

後者は、例えばユーザー体験の向上やフィードバックのためにユーザーのキーストロークの取得やスクリーンショットの撮影を行うスクリプトなどを埋め込んだ際に、v2までは意図せずユーザーが入力したカードの情報を取得できてしまう状態でした。

より分かりやすく、v2v3それぞれでカード情報入力フォームが表示されているページのJavaScriptからスクリーンショットを撮る実験を行ったところ、以下のような結果になりました。(JavaScriptからのスクリーンショットの撮影にはhtml2canvasというライブラリを用いています)

images

上記の画像から確認できる通り、v2ではカード番号を含めた入力フォームの内容が撮影できているのに対し、v3ではカード情報入力フォーム全体がiframeとなりオリジンを超えてるため、撮影できてないことが確認できます。

PCI DSSの実装区分SAQ Aに該当させる

このバージョンアップは、PCI DSSで新たに運用が始まったSAQ(Self Assessment Questionnaire)のA-EPとSAQ Aという2つの実装区分の登場にキャッチアップしています。

SAQ A-EPとSAQ Aという言葉自体に馴染みがないため、PCI DSSは耳にしたことがあるという方でも詳しくご存知ではない方もいらっしゃると思います。詳しく知りたい方はPCI DSSv3.0のSAQ A-EPとAは何が違うのかの内容が参考になります。

簡単に2つの実装区分の違いを説明しておくと、SAQ A-EPは全てのカード番号の処理がPCI DSS準拠のサービスプロバイダーにアウトソースされる場合と示されているのに対して、SAQ-Aはすべてのカード番号の入力と処理がPCI DSS準拠のサービスプロバイダーにアウトソースされている場合と示されています。カード番号の入力がどのドメインに対して行われているかという点がポイントとなっています。

また、クレジットカード決済を導入するサービス事業者(加盟店)の観点から見た場合、カード番号へのアクセス性の違いからSAQ A-EPとSAQ Aのいずれを利用しているかによってPCI DSSの準拠項目が大きく異なる点が重要となります。

SAQ Aの場合、SAQ A-EPと比べるとサービス事業者側の準拠コストが低下します。SAQ Aの実装を行った場合、加盟店の準拠コストは300超の要件の中の14要件のみに準拠すれば良いのに対して、SAQ A-EPの実装を行った場合、139要件への準拠が必要になります。

今回の変更によって、すでに本記事の中で説明しているとおりですが、サービスプロバイダーのドメインwebpay.jp内にカード番号を入力するように変更され、実装区分はSAQ Aに該当することになります。(v2以前やWebPay.jsを用いる場合にはSAQ A-EPに該当します)

PCI DSSに基づくセキュリティの観点からもSAQ Aに該当出来る実装であるv3を用いることが推奨されます。

注意

今回のバージョンアップは、あくまでもユーザーのカード情報などが別オリジンから取得されないようにするための対策であり、不意なカード情報の閲覧などを防ぐためのものです。

任意のJavaScriptなどがページに埋め込まれてしまった場合はこの限りではありませんので、引き続きクロスサイトスクリプティング(XSS)などの脆弱性の対策を十分に行なわれるようお願いいたします。