アカウント名:
パスワード:
意外と知らない人が多いのかな。保存が禁止されているCVVが流出するのは保存されていたからだ、CVVを保存するのはおかしい、と指摘する人はしばしばいますが、この手の流出はサーバに入られて入力内容を外部送信するよう決済ページを改竄されることで起きます。なので元からCVVを保存する仕様だったかどうかとか、データベースに何が保管されていたかは必ずしも関係ないです。
極端な話、必要な情報が抜けているなら攻撃者側で入力欄を書き加えてあげればいいわけですから。
読売ファミリー.comの発表文から想像すると、JINSと同じ [security.srad.jp]でサーバー書き換えられて、入力したフォーム内容をそのまま第三者サーバーに送ったんじゃないかな？
そう考えると改ざん日からが盗まれた可能性のある取引になるし、CVVとか全部ぶっこ抜きされたのもよくわかる。一方、JINSでこういう手口があったんだとわかっているんで改ざんされないようなシステムにしておくべきだったんだろうなぁ。
一方、カード番号漏洩事例なのでフォレンジックできる会社は限られているんですが、その会社名出さないとなぁ。大昔にサウンドハウスがカード情報漏洩やった際にLACに依頼してたけど、あそこはクレジットカード会社の認めるフォレンジック認定取ってないのよね。
> クレジットカード会社の認めるフォレンジック認定
まあ、日本がサービスエリアになってるのは6社、日本に拠点があるのは2社しかないからね。
https://www.pcisecuritystandards.org/assessors_and_solutions/pci_foren... [pcisecuritystandards.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
保存する仕様だったとは限らない (スコア:4, すばらしい洞察)
意外と知らない人が多いのかな。保存が禁止されているCVVが流出するのは保存されていたからだ、CVVを保存するのはおかしい、と指摘する人はしばしばいますが、この手の流出はサーバに入られて入力内容を外部送信するよう決済ページを改竄されることで起きます。なので元からCVVを保存する仕様だったかどうかとか、データベースに何が保管されていたかは必ずしも関係ないです。
極端な話、必要な情報が抜けているなら攻撃者側で入力欄を書き加えてあげればいいわけですから。
Re:保存する仕様だったとは限らない (スコア:0)
読売ファミリー.comの発表文から想像すると、JINSと同じ [security.srad.jp]でサーバー書き換えられて、入力したフォーム内容をそのまま第三者サーバーに送ったんじゃないかな？
そう考えると改ざん日からが盗まれた可能性のある取引になるし、CVVとか全部ぶっこ抜きされたのもよくわかる。一方、JINSでこういう手口があったんだとわかっているんで改ざんされないようなシステムにしておくべきだったんだろうなぁ。
一方、カード番号漏洩事例なのでフォレンジックできる会社は限られているんですが、その会社名出さないとなぁ。大昔にサウンドハウスがカード情報漏洩やった際にLACに依頼してたけど、あそこはクレジットカード会社の認めるフォレンジック認定取ってないのよね。
Re:保存する仕様だったとは限らない (スコア:1)
> クレジットカード会社の認めるフォレンジック認定
まあ、日本がサービスエリアになってるのは6社、日本に拠点があるのは2社しかないからね。
https://www.pcisecuritystandards.org/assessors_and_solutions/pci_foren... [pcisecuritystandards.org]