アカウント名:
パスワード:
>住宅金融支援機構サイトではカード番号と有効期限に加えセキュリティコード
セキュリティコード漏洩は言い訳がきかぬ。
セキュリティコードは本来はカード会社以外が保管する必要もないはずだが...これはダメすぎる
元Q2屋がやられたんかw
GMOペイメントって言う名前をみて、ちょっと嫌な予感はしたんだけど流石に東京都もそれなりの審査はしてるんじゃないかと思ったんだが、ダメだったか・・・。
年末のカゴヤの件 [kagoya.jp]に続いて、またってのは痛すぎるし、面倒くさすぎる・・・。よりによって、カードも違うので、もう一回手続きかよ・・・。こんどはあっちこっちの定期引き落としになってるからものすごい手間だぞ。
#業務委託者の責任もあると思うのだが、どうなんだろ?
この場合、東京都は指定しただけで、委託者はあなたになりますが、契約を理解せず委託したということで、ご自分自身で責任を取られるということでしょうか。
PCI DSSに準拠しているなら、カード番号漏洩も言い訳できませぬ。保存するなら読み取り不能・予測不能にする(一方向ハッシュ関数を使う、最初の6桁と最後の4桁を超えて保存しないようにする、業界テスト済みのアルゴリズムで暗号化するなど)必要があり、それが検証されているはずですから。(要件3.4)
与信関係ライブラリーのガイド・マニュアルにはセキュリティコードは保存するなと書いてありそうな気がするのだが……
基本的なことすらできてないのはセキュリティ意識以前だろう。
クレジットカード業界のセキュリティ基準 PCI DSS(Payment Card Industry Data Security Standard)の『Payment Card Industry(PCI)データセキュリティ基準 要件とセキュリティ評価手順バージョン 3.0』には「機密認証データは承認後、たとえ暗号化していても保存してはなりません。」とはっきり書いてあります。(CAV2/CVC2/CVV2/CID〔いわゆるセキュリティコード〕は機密認証データに含まれることも書いてあります)日本語版はv3.0が最新のようですが、その10ページに書いてあります。ちなみにPCI DSSのドキュメントはメールアドレス登録で見れます。
追伸。業務委託している側(トヨタファイナンス?)にも責任ありです。
『PCI DSS 要件はアカウントデータ(カード会員データや機密認証データ)が保存、処理、または送信される組織と環境に適用されます。一部の PCI DSS 要件は支払業務や CDE 管理をアウトソースしている組織にも適用されます。CDE や支払業務を第三者にアウトソースする組織はまた、アカウントデータが 第三者により PCI DSS 要件に従って保護されていることを確認する責任があります。』
トヨタファイナンスは完全にアウトでしょう。ロゴや名前を出してる東京都も確認義務があって然るべきと思います。『委託先がやっちまったよ、ごめんね』では済まない。なんとかファイナンスとか、なんとかペイメントとか、いかにも金融取引・支払い業務を専門にやる社名の業者なのだから。
よくみると、GMOペイメントゲートウェイの言い訳文 [gmo-pg.com]の下の方には
「GMOペイメントゲートウェイのサービスはPCI DSSに完全準拠しております。」
とか書いてあって、もう笑うしかないですね。
トヨタファイナンスの方も2.0だけどカード会員用インターネットサービスにおいて「PCI DSS ver.2.0」準拠認定を取得 [toyota-finance.co.jp]とかあるので、こちらもなんだか。
それより気になったのは、同じトヨタファイナンスーGMOペイメントゲートウェイの枠組みで、三重県自動車税 [toyota-finance.co.jp]、愛知県県税 [toyota-finance.co.jp]、大分県自動車税 [toyota-finance.co.jp]、福岡県自動車税 [toyota-finance.co.jp]、福岡市税 [toyota-finance.co.jp]なんかもやってるみたいなのだが、こちらは大丈夫なのだろうか?
いや、“流出した可能性がある、だがそれは保存していたからではないいい。メモリ内ならセーフなんだからあ”という解釈が・・
その解釈ができる可能性ってあるよね。そのほうが現実的。
いや、Javaは無難な選択というかそこ本質でなくて、Struts使っているっていうところがなんとも。
多分セキュリティを知らない、っていうかセキュリティは英語なんですか?レベルで知らないというか、そもそも自分が派遣された会社の仕事内容を全くしらないというか出社すらしない人が意思決定という名の放置プレイしてるんじゃないですかね。
Javaが無難な選択と思っちゃうような人って往々にしてJavaだけしか知らない人だからねぇ・・・
Javaだけしか知らない人達しか揃えられない、かもしれん。
#Javaで作るのは難しい、と誰かが言ってたなあ
「Javaも名前しか知らない」なんだな。良くてC,COBOL(これも名前だけ)。基本的に一行も読めない。ガチで。
♯Jar Hellなモノしか見たこと無いな
#3174724ですが、なんか話かみ合ってないけど、javaっていう言語の話でなく、Strutsのウンコ具合が問題なのであって。https://srad.jp/comment/3174677 [srad.jp]
java出来る人とPHP出来る人、そなたが沼に落としたのはどちらか?って聞かれたら、「単価の安い人です」って言っちゃうな。どっちもどっちだし。
javaいいですよ? scalaたのしー。※ VMの感想です。
良く考えてもJavaは無難なところが話題をややこしくするかもね。※ パフォーマンス、エコシステム、言語の寿命とかを考えるとこのシステムならJavaで作る方が楽。RubyやPHPだとバージョンアップがめんどい。
「いまどきJavaなんて」って言う人って、Rubyとか https://www.cvedetails.com/product/12215/Ruby-lang-Ruby.html?vendor_id=7252 [cvedetails.com] Railsとか https://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.htm... [cvedetails.com] のセキュリティアドバイザリ見てないのかな。Javaのやつ https://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 [cvedetails.com] と見比べると、code execution とかそういうヤバい奴の発生率は同程度のオーダーでしかないんだけど(2013年はひどいけど)。
ヤバいのはPHPとかでしょ。 http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id= [cvedetails.com]
> ただし Struts は Code Execution みたいに超深刻な問題の発生率が高くてヤバい。> https://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 [cvedetails.com]
リンク間違えました。正しくはこちら。https://www.cvedetails.com/product/6117/Apache-Struts.html?vendor_id=45 [cvedetails.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
はいあうと~ (スコア:2, 興味深い)
>住宅金融支援機構サイトではカード番号と有効期限に加えセキュリティコード
セキュリティコード漏洩は言い訳がきかぬ。
Re:はいあうと~ (スコア:1)
セキュリティコードは本来はカード会社以外が保管する必要もないはずだが...
これはダメすぎる
Re: (スコア:0)
元Q2屋がやられたんかw
Re: (スコア:0)
GMOペイメントって言う名前をみて、ちょっと嫌な予感はしたんだけど流石に東京都も
それなりの審査はしてるんじゃないかと思ったんだが、ダメだったか・・・。
年末のカゴヤの件 [kagoya.jp]に続いて、またってのは痛すぎるし、面倒くさすぎる・・・。
よりによって、カードも違うので、もう一回手続きかよ・・・。
こんどはあっちこっちの定期引き落としになってるからものすごい手間だぞ。
#業務委託者の責任もあると思うのだが、どうなんだろ?
Re: (スコア:0)
この場合、東京都は指定しただけで、
委託者はあなたになりますが、
契約を理解せず委託したということで、
ご自分自身で責任を取られるということでしょうか。
Re: (スコア:0)
>住宅金融支援機構サイトではカード番号と有効期限に加えセキュリティコード
セキュリティコード漏洩は言い訳がきかぬ。
PCI DSSに準拠しているなら、カード番号漏洩も言い訳できませぬ。
保存するなら読み取り不能・予測不能にする(一方向ハッシュ関数を使う、最初の6桁と最後の4桁を超えて保存しないようにする、業界テスト済みのアルゴリズムで暗号化するなど)必要があり、それが検証されているはずですから。(要件3.4)
Re: (スコア:0)
与信関係ライブラリーのガイド・マニュアルには
セキュリティコードは保存するなと書いてありそうな気がするのだが……
基本的なことすらできてないのはセキュリティ意識以前だろう。
Re:はいあうと~ (スコア:4, 参考になる)
クレジットカード業界のセキュリティ基準 PCI DSS(Payment Card Industry Data Security Standard)の
『Payment Card Industry(PCI)データセキュリティ基準 要件とセキュリティ評価手順バージョン 3.0』
には「機密認証データは承認後、たとえ暗号化していても保存してはなりません。」とはっきり書いてあります。
(CAV2/CVC2/CVV2/CID〔いわゆるセキュリティコード〕は機密認証データに含まれることも書いてあります)
日本語版はv3.0が最新のようですが、その10ページに書いてあります。
ちなみにPCI DSSのドキュメントはメールアドレス登録で見れます。
Re: (スコア:0)
追伸。業務委託している側(トヨタファイナンス?)にも責任ありです。
トヨタファイナンスは完全にアウトでしょう。ロゴや名前を出してる東京都も確認義務があって然るべきと思います。
『委託先がやっちまったよ、ごめんね』では済まない。なんとかファイナンスとか、なんとかペイメントとか、いかにも金融取引・支払い業務を専門にやる社名の業者なのだから。
Re:はいあうと~ (スコア:2, 興味深い)
よくみると、GMOペイメントゲートウェイの言い訳文 [gmo-pg.com]の下の方には
とか書いてあって、もう笑うしかないですね。
トヨタファイナンスの方も2.0だけどカード会員用インターネットサービスにおいて「PCI DSS ver.2.0」準拠認定を取得 [toyota-finance.co.jp]とかあるので、こちらもなんだか。
それより気になったのは、同じトヨタファイナンスーGMOペイメントゲートウェイの枠組みで、三重県自動車税 [toyota-finance.co.jp]、愛知県県税 [toyota-finance.co.jp]、
大分県自動車税 [toyota-finance.co.jp]、福岡県自動車税 [toyota-finance.co.jp]、福岡市税 [toyota-finance.co.jp]なんかもやってるみたいなのだが、こちらは大丈夫なのだろうか?
Re: (スコア:0)
いや、“流出した可能性がある、だがそれは保存していたからではないいい。メモリ内ならセーフなんだからあ”という解釈が・・
Re:はいあうと~ (スコア:1)
その解釈ができる可能性ってあるよね。そのほうが現実的。
Re: (スコア:0)
いや、Javaは無難な選択というかそこ本質でなくて、Struts使っているっていうところがなんとも。
多分セキュリティを知らない、っていうかセキュリティは英語なんですか?レベルで知らないというか、
そもそも自分が派遣された会社の仕事内容を全くしらないというか出社すらしない人が意思決定という名の
放置プレイしてるんじゃないですかね。
Re: (スコア:0)
Javaが無難な選択と思っちゃうような人って往々にしてJavaだけしか知らない人だからねぇ・・・
Re: (スコア:0)
Javaだけしか知らない人達しか揃えられない、かもしれん。
#Javaで作るのは難しい、と誰かが言ってたなあ
Re: (スコア:0)
「Javaも名前しか知らない」なんだな。
良くてC,COBOL(これも名前だけ)。
基本的に一行も読めない。ガチで。
♯Jar Hellなモノしか見たこと無いな
Re: (スコア:0)
#3174724ですが、なんか話かみ合ってないけど、javaっていう言語の話でなく、
Strutsのウンコ具合が問題なのであって。
https://srad.jp/comment/3174677 [srad.jp]
java出来る人とPHP出来る人、そなたが沼に落としたのはどちらか?
って聞かれたら、「単価の安い人です」って言っちゃうな。どっちもどっちだし。
javaいいですよ? scalaたのしー。
※ VMの感想です。
Re: (スコア:0)
良く考えてもJavaは無難なところが話題をややこしくするかもね。
※ パフォーマンス、エコシステム、言語の寿命とかを考えるとこのシステムならJavaで作る方が楽。RubyやPHPだとバージョンアップがめんどい。
Re: (スコア:0)
「いまどきJavaなんて」って言う人って、Rubyとか
https://www.cvedetails.com/product/12215/Ruby-lang-Ruby.html?vendor_id=7252 [cvedetails.com]
Railsとか
https://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.htm... [cvedetails.com]
のセキュリティアドバイザリ見てないのかな。Javaのやつ
https://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 [cvedetails.com]
と見比べると、code execution とかそういうヤバい奴の発生率は同程度のオーダーでしかないんだけど
(2013年はひどいけど)。
ヤバいのはPHPとかでしょ。
http://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id= [cvedetails.com]
Re: (スコア:0)
> ただし Struts は Code Execution みたいに超深刻な問題の発生率が高くてヤバい。
> https://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 [cvedetails.com]
リンク間違えました。正しくはこちら。
https://www.cvedetails.com/product/6117/Apache-Struts.html?vendor_id=45 [cvedetails.com]