モグステーションにおけるクレジットカードの認証について

[Anemone-aura]

もし私がWebページ製作依頼者であれば有無を言わせずRejectする仕様です

と書かれているのでウェブの決済系にはそれなりに知識があると思うんですけど、ここで使われている3Dセキュアはiframeを使う仕様なので、3Dセキュアを使っている限りはスクエニ側では対応しようがないと思います。

3Dセキュア(wikipedia)

最初の頃の3Dセキュアはおっしゃるようなポップアップウィンドウを使っていました。ところがそのためにポップアップウィンドウを間違って閉じてしまったり、そもそも開かせない設定にブラウザーがなっていたりなどでトラブルが絶えず、今のようなiframeを使う仕様に変わりました。

3Dセキュアを使わずにショップ側で全て済ますようにすることも可能ですけど、その場合クレジットカード会社によっては意図しないカードの不正利用があった場合に補てんを拒否される場合もあります。日本のカード会社は実際の物品が伴わない商品の決済についてはかなりうるさいので。

クレジットカード会社による安全性確認を諦めてもいいならiframeを使わない方法にできるでしょうけど、私としては困るので現行の状態で特に問題ありません。

あとiframe自体は現状例えばYouTubeの埋め込みなど多くのサイトで多用されていますから、ことさらそこだけ問題にして「iframeは安全性が低い」と言わなくてもという気もしますけど。

[Minna]

すみません。略させていただきます。

モグステーションで使用されているセコムのクレジット情報入力フォームはiframeを使う仕様なのでしょうが、3Dセキュア画面はその仕様ではありません。
現に、他のサイト（例：DLsite.comなど）では、各フォームにそのまま推移していきます。（無論、3Dセキュアのフォームにも推移していきます）
その際、アドレスにてSSL証明の是非が一見して見えることになり、ユーザー視点で見た場合比較的安心できる内容となります。

また、SSL証明に関してもいくつかレスがありましたが、証明可能範囲は証明書に記載したドメインのみ（ワイルドカード指定があればサブドメイン含む）です。
現モグステーションのような、外側：secure.square-enix.com　/　iframe内：www5.econ.com　であれば、外側のsecure.square-enix.comは証明できますが、www5.econ.comの方は範疇外となります。
www5.econ.comの方は、そちらもSSL証明書が存在し、それで証明可能ですがiframeの場合一見してそれを把握することが出来ません。（尚、ecom側はEV SSLではないため組織名は出ませんが）
#ユーザーの検証可能性を下げている。

PCに詳しくない方であればより顕著になることでしょう。
そんな人々にも、証明書による確認が取れていることを見せて決済させるのが、使う側への安心感を生むと考えます。

尚、OWASP（Open Web Application Security Project）が発行するセキュリティ要件定義書にも、iframeは望ましくないとされています。
https://github.com/ueno1000/secreq/b...rements2.0.pdf

更にいえば、このようなお金が絡むものと、Youtubeのiframe表示を同列に考えてはいけません。

[RARUA]

難しいことはよく分からんけど、とりあえず一言
「そんなに疑うならゲームそのものをやめれば良いじゃん」

[AerialLuster]

省略

尚、OWASP（Open Web Application Security Project）が発行するセキュリティ要件定義書にも、iframeは望ましくないとされています。

使用してはならないであったり、使用すべきではないという文言ならまだしも、
ソフト開発で望ましくないという弱い表現だと、使用することを容認しているようなものかと。。。

望ましくないということは、よほど特殊な環境でなければ脆弱性は発現しないと言っているのと同じです


仮にある機能を実現する場合に、とり得る手段がいくつかあるような場合を考えて、
QCD（品質、コスト、納期）を勘案して、推奨されない手法で実装をするほうが大きく有利であった場合には、
使用すべきでない要件であれば別な手段を模索しますが、
望ましくない程度の要件であればよほどのことが無い限り
そのまま実装してしまうことのほうが多いのでは？
（仕様書に注意事項として記載するだけで終わることが多い


例で挙げられているモグステーションの入力フォームをiframeで実装する方法と、
DLsite.comで使用されている入力フォームを比較した場合に、
まずフォームをホストしている組織のサーバー・ネットワーク機器などの管理体制や、
コスト、実装を比較したときに、DLsite.comで使用されている入力フォームが極めて優れているというような状況でもない限り、
iframeでの実装が選択肢に入ってくるのは別におかしなことではないのではないかと思います



また、Minnaさんはアドレスが見えたほうが安心するのかもしれませんが、
不必要なサイトの遷移が発生しない構成であったほうが、
どこか怪しいところに飛ばされているのではないか？と不安に思う人にとっては望ましい構成であり、
一概にどちらのほうがいいとはいえないと思いますよ？
（そもそも、PCに詳しくない人がSSLの情報とかアドレスとか見て本当に安心できるの？っていう話も。。。

[Minna]

略させていただきます。

それでは合わせてこちらもお読み下さい。
－安全なWebアプリ開発の鉄則2006
https://www.nic.ad.jp/ja/materials/i...edings/T21.pdf
#39頁から。

－フィッシング対策ガイドライン　2015年度版
http://www.antiphishing.jp/report/pd...hing_guide.pdf
#10頁後半から。

通常のページならまだしも、ユーザーの金銭に関わるページであれば、セキュリティは強固にすべきです。それに対してコストがかかるとしても。
「コストがかかるから」「利便性が悪いから」などで、簡単な方へとシフトすると、それは脆弱性またはそれに類するものの種を残したままとなり、非常に危険です。
どこまでも強固にしていて、時が経つにつれそれも破ってしまう手法が見つかるかもしれません。なのでこのようなセキュリティ事項には日々アンテナを伸ばし、時代に合った強固な策に更新していかなくてはなりません。これは金銭等をやり取りする上での企業責任です。

また、Minnaさんはアドレスが見えたほうが安心するのかもしれませんが、
不必要なサイトの遷移が発生しない構成であったほうが、
どこか怪しいところに飛ばされているのではないか？と不安に思う人にとっては望ましい構成であり、
一概にどちらのほうがいいとはいえないと思いますよ？
（そもそも、PCに詳しくない人がSSLの情報とかアドレスとか見て本当に安心できるの？っていう話も。。。

先にも書きましたが重要なのは『ユーザーの検証可能性』です。iframeを使うことはこれを著しく下げます。
このスレッドではスクエニ側のモグステーションでの議論にしていますが、可能ならば3Dセキュアフォームを設けているセコム側にも言いたいですねぇ。
ちゃんとEV-SSLを取得しろ、と。

[AerialLuster]

今回は超大作になってしまった。。。

それでは合わせてこちらもお読み下さい。

省略

提示されている資料は読んだことありますが。。。。
ちゃんと内容を理解されていますか？

1）アドレスバーを隠してはいけないのは、昔あった単独のウィンドウでアドレスバーを隠す設計の場合
2）サブフレームがhttpsで外枠がhttpというのは、モグステがhttpでiframeがhttpsという設計の場合で、
この場合はサブフレームの情報が属性を正しく設定されていないクッキーなどを介して
入力情報やセッション情報を窃取される可能性があることと、
外枠がhttpであるため、モグステの偽サイトへの誘導やモグステ自体が改竄される恐れがあるため
3）サブフレームのドメインが外枠と異なるというのは、httpの場合で、上記の偽サイトや改竄の恐れと同様
4）サブフレームに偽サイトが表示されるというのは、サイト自体が改竄された場合

1は問題外にしても、
2はそもそもモグステはhttpsであり、アドレスバーにはスクエニのサイトであることが一目でわかるようになっています
また、SSLである限り経路上の改竄は極めて低く、サイト自体の改竄やモグステで入力された内容が窃取される可能性は、
a）スクエニに悪意や瑕疵がある
b）決済システム提供会社に悪意や瑕疵がある
c）スクエニまたは決済システム提供会社のサーバーに不正アクセスがあった
d）ユーザーのPCに不正プログラムが組み込まれていた
等が考えられますが、aやbだと考えるなら機微な情報の入力はされないことをお勧めしますが、
cやdであるならiframeなどとはそもそも一切関係ありませんよね？
同様に、3と4も2と同じことが言えます

モグステがSSLでサイトの正当性を保証しており、決済システムもSSLで保護されている以上、
これらの内容にはそもそも当てはまっていないと思いますが・・・？