サウンドハウスの情報流出の経緯のまとめ 133
タレコミ by peyoung
peyoung 曰く、
情報元へのリンク
4月18日付けの 不正アクセスに伴うお客様情報流出に関するお詫びとお知らせからリンクされているPDF文書が興味深い。
サウンドハウスでカード情報漏洩の経緯が詳細に書かれている。どういった攻撃があったのか、情報公開が遅れた理由、関わった会社はどこか、当時と現在のセキュリティ体制など、こういった事件のときにあまり表に出てこない情報が満載です。ためになりました。
情報元へのリンク
殆ど「ほっかむり」状態を決め込むよりはずっとまし (スコア:5, 興味深い)
--- Toshiboumi bugbird Ohta
要するに (スコア:3, 興味深い)
独自開発なのに2008年の時点でSQLインジェクションを知らなかったなんて……。しかも知らなかったのは行政のせいだなんて……。
これを読んで、この社長が経営する会社のサイトは今後も使わない方がいいと私は思いました。
Re:要するに (スコア:5, 参考になる)
全く知らないのでなく、セキュリティには金を払っているのだから、
これで防げるのではないかと思っていたという事でしょ。
技術の専門家で無かった自分は「ハッカーセーフ」とやらの謳い文句が、
十分投資に見合った体制だと思っていたと20ページ目に書いている。
技術の専門家だったら責めるのも解るけど、エンドユーザーの態度としては、
こんなもんじゃないかなあとも思うんだけど。
>知らなかったのは行政のせいだなんて
この会社、この社長の発言全てを弁護するわけじゃないがOffice氏の事件以降、
善意の第三者が危険な状態になっている事をお知らせというのは激減している。
そこに、セキュリティ情報の提供が難しくなっている背景があると思う。
「2006年6月19日に名指しされていた」事が、当時の社長に伝わらなかった。
そしてその間、効果があると思っていた「ハッカーセーフ」に頼り切っていた。
これは、セキュリティの生々しい情報（攻撃側の最新情報
、防御装置の防御範囲）が
表に出てこないからで、素人は学ぼうにも限界があったという事でしょう。
・生々しい情報を公開する
これを言いだしっぺの法則でやってから、注文してる態度は評価してもいい。
それでエンドユーザーの無知ばかりを責めたてるのは得策とは思えない。
例えば、それぞれのセキュリティソリューションの実効性をチェックして公開とか、
各社セキュリティプランの保護領域を比較してくれる第三者機関とか、
エンドユーザーが望む情報がエンドユーザーが危険を冒すことなく、
エンドユーザーの知識で理解できて、コストの不安が無い仕組みが提供できるとすれば、
行政という言葉になってしまうのじゃないかな。
IPAでも情報は公開しているけど、サウンドハウスのようにある程度、
ソリューションを導入していると「ウチに限って」と思い込むのはありうるし、
「ハッカーセーフ」を提供した会社だって「これじゃ不安です」とは言わない。
Re:要するに (スコア:4, 興味深い)
>十分投資に見合った体制だと思っていたと20ページ目に書いている。
ここ不思議ですよね。「ハッカーセーフ」というのはSQLインジェクションの脆弱性の診断もやってくれるのだそうですが。
http://www.hackersafe.jp/product/point.html [hackersafe.jp]
「中国のブログ」の記述では、SQLインジェクションの脆弱性をスキャンツールで発見しているようですから、このサービスも当然脆弱性を見つけていたのではないかと思うのですが。どうなんでしょう。
Re:要するに (スコア:2, 参考になる)
HackerSafeのやってるSQLインジェクションチェックは、
サードパーティ製品などに見付かっている既知の問題クエリとかで、決まったパターン。
で、今回問題だったのは、サイトカスタムなSQLインジェクションで、決まってないパターン。
まぁ、売る側からすれば「SQLインジェクション」診断してますと言うが、
実際には無駄なパターンを数多くたれ流しているだけに過ぎず、いざというときの役に立たない。
安かろう、悪かろうな典型だわな。
だがこれは、別にHackerSafeが悪いわけじゃない。
問題は、正しくリスク分析ができなかった連中が悪いんだ。
今回の件くらいの規模のリスクが発生することを見越していれば、
定期的に人力で診断するなりなんなり出来たはずだろう。
Re:要するに (スコア:2, 参考になる)
>Office氏の事件以降、善意の第三者が危険な状態になっている事をお知らせというのは激減している。
そのOffice事件を受けてIPAやJPCERTなどの取り組みが制度的に整備されました。
そののち、それまで問題点を発見しても誤解されることを恐れて通報を躊躇していた善意の第三者の皆さんは、多少の不安も感じながらそれらの取り組みに加わっています。
したがって、善意の第三者が直接「問題のある組織団体」や「ネット上」へ危険な状態になっている事をお知らせというのは激減していますが、それは当たり前のことで、むしろ通報する側される側とも余計なリスクを負うことが無くなったことは歓迎すべきだと思います。
IPAやJPCERTもJVN準拠で処理されており、その線で情報公開も行われています。
また自分がかかわった案件の経緯をブログ等で公開している開発者もいます。
脆弱性情報が閉ざされたり闇に葬られるようになったわけではありません。
サウンドハウスも企業としてIPAにきちんと報告しています。
その結果、経産省のヒアリングを受けますが、これは単なるご説明ではなく、多量流出案件に対するペナルティの意味を有しています。
つまり単なる情報流出事件ではなく、流通と金融に係るトラブルであると経産省が認識しているのであり、外郭団体と中央省庁の連携がきちんと機能していることを表しています。
Office事件は通報者自身の不手際もあり逮捕者も出しましたが、その教訓はきちんと生かされているのではないでしょうか。
Re:要するに (スコア:2, 興味深い)
(略)
>その教訓はきちんと生かされているのではないでしょうか。
レスありがとうございます。
この部分、自分でも最後まで触れずにいようかと思いましたが、やはり触れることにしました。
このようなツッコミが入る程度には、IPAの活動は周知されているのか、普通にOffice事件から
進展がないと受け止めている人が多いのか解らなかったからです。
あれ以降、確かに軽微なものはリスクを負う事無く報告されるようになりました。
そして問題が起きた後のインシデントレスポンスの体制は整ったかもしれません。
しかし、今回の経緯 [srad.jp]を見て、そして自分が通報したときの経験からすると充分といえません。
・「海外における善意の第三者」の通報には対応していないか、窓口が知られていない
逆に一見日本語が提供されていても、グローバル企業、日本以外に本拠点のあるサイトへの対応は弱い
・今回のような脆弱性を全個所（SQLインジェクション以外の部分）報告する事は歓迎されない
そこを糸口にした影響範囲を調査する事は逆に制限がついている
・報告しても放置が多いのに全く公開されず公開できず、その間ユーザーは危険に晒されつづける
具体的事例を蓄積しているはずなのに、統計的にしか知ることが出来ない
という問題を依然抱えているように思えるからです。
>Office事件は通報者自身の不手際
これがたまたま、比較的オープンな集会であったために発覚しましたが、今回のようにアンダーグラウンドで
取引されているような脆弱性情報 [impress.co.jp]のような、
即警察にも動いて欲しい事案を報告するにはIPAの窓口だけでは不足です。
（場所によっては、裏切り者となって殺されるリスクがあるかもしれません）
そして、ソフトウェア事例ですが一太郎の脆弱性が、シマンテックのブログで公開された事例について
高木浩光氏 [takagi-hiromitsu.jp]も「一太郎zero-day攻撃のニュースは、
次のように、いつも Symantecの blog が一次情報源になっている。」と書いています。
（まあ、氏のblogなので、やや煽り気味である表現があるのは無視して読むことが必要ですが）
要するに、海外の善意の第三者は依然Office流とも言える対応をしているし、悪意のある人間は尚更です。
日本国内の善意の第三者だけが守るような取り組みで、その善意の示し方も慎重なやり方に制限されています。
結果的に、通知された側は本当のリスクが見えなくなっています。
脆弱性を通知された組織の側から、間近に問題がどう受け止められたかを見た事もあります。
私は当該アプリケーションの実装もしていなければ、何か決定する権限が与えられている訳では
ありませんが、他に誰もその脆弱性報告がどういう攻撃をされるのに利用されて、
一番大事な所ですがビジネスリスクになるのが解らないという事で相談された事があります。
IPAからの報告は、技術者に届かなければ意味が通じず効果がないという事なのです。
統計的なデータ [security-next.com]だけでは、わが社に限って狙われることは無いと思ったりするのです。
特にクロスサイトスクリプトのようなものは、「これまでにこれでこういう事例があった」
みたいな一時報告者は知らなくてもIPAが蓄積しているであろう具体的なソースを提示しないと、
すぐにエスカレーションされる機会が殆ど無いのです。
例えばSQLインジェクションでは、会員の情報を抜いて見せて報告をすればいいのですが、
一度そういう報告をすると「これ…訴えられるかもしれないよ」とお叱りを頂きます。
だからシングルクォートを入れたらSQLエラーが画面に出た、程度の情報で報告します。
では、そこからIPAが相手と同意をとって検証して、会員情報リストが抜ける形を示して
くれるかというとそうでは無いので、よほど日頃からセキュリティ事情に関心をもっている、
CIOでも置いていない限りビジネスリスクとして認識してくれません。
オフショアに丸投げにして作られたものなどは、解っていても「契約外、仕様外」といって、
直すのに新規構築に負けないくらいの金と労力がとられるので躊躇する場面もあるようです。
まあ、SQLインジェクションは、もはや名前だけが一人歩きするようになっているので、
「とにかく対策しなければ」と思う人のほうが多いと思ってしまいます。
しかし、44件残っているうち1年以上放置されているのが20件 [nikkeibp.co.jp]というのが実情です。
しかも、今回のような事案の場合、「この欄に'を入れたらエラーが出たよ」どまりの報告では、
抜本的な対策を取る事無く別欄のインジェクションで攻撃されている不安が残ります。
ラックさんとの協力でツールを公開 [atmarkit.co.jp]してくださったようですが、
これは複数台サーバーにわたる膨大なログを定期的に自動処理出来ないので実行コストが嵩みます。
すると、結局元々意識の高い会社が「ああやっぱり攻撃されてなかったね、よかったね」という確認を
自主的に行って安心する程度になってしまう可能性が高いです。
これまでの、「統計的な取り組みは評価に値する」「あの頃に比べれば改善したと思う」という意味で、
その認識は貴方と同じですが、今回の事例からハッカーセーフを導入するようにはなったが、
しかしそのソリューションが一体何を守っているのか解っていないでやっているという実態が
明らかになり、ウェブをやってるのは技術者がいる会社だから技術者に解る内容で公開すればいい、
という性善説的な従来の限界、日本国内ルールの限界が見えてきたと思います。
IPAの実効性に論点が膨らみすぎましたので、Office事件後と事件前の話だけに絞りましょう。
Office氏のやった事は、発表の場とプロセスが悪かったにせよ具体的なプレゼンでありました。
あれ以降、IPAに報告をすることで、具体的なプレゼンを必要としなくなってはいるが、
それだけに充分相手に伝わらなくなっているという事です。
Re:要するに (スコア:5, すばらしい洞察)
構造計算書や産地や原料の偽装だってバレるまではひた隠しにした方がいいに決まってるんです。社会正義なんて嘯く連中にだまされてはいけません。
Re:要するに (スコア:2, おもしろおかしい)
＃「くいだおれ」にもいなかった。
Re:要するに (スコア:3, すばらしい洞察)
今回の事件を受けて所感・提言の
2つに分ければいいのに、と思った。
ここに限らず、お詫び文と一言もの申すをひとつに束ねちゃうと
発言側の意図しない受け取られ方をするのになぁと常々思う。
Re:要するに (スコア:2, 参考になる)
文面を読む限りだと「SQLインジェクションを知らなかった」と言うわけではなくて、「SQLインジェクションの危険性を知らなかった」ということだと思いますよ。
行政云々～っていうのはそれを受けての発言だと考えれば、社長の言い分も分からなくはないです。
// まぁでも行政へ責任転嫁する姿勢は私もどうかと思いますけどね。
// 社長の言い分が正しいとなれば極端な例で「Windows使うのは危険」「Linux使うのは危険」と
// 行政は言わなくてはならなくなると思います。あくまで極端な例ね。
// 「はさみを使うと手を切る危険があります」なんて行政がアラート出すわけありませんものねぇ
// だからはさみメーカーは「こどもの届かないところに置いて！」って警告を書いているわけですし
Re:要するに (スコア:4, 興味深い)
＞文面を読む限りだと「SQLインジェクションを知らなかった」と言うわけではなくて、
ここの話 [itmedia.co.jp]によると、サウンドハウスはSQLイジェクション自体を知らなかったようですよ。
Re:要するに (スコア:1)
Re:要するに (スコア:2, 興味深い)
一部だけ取り出して読むとそういう意見もあるでしょうが、私は社長の心情も含め赤裸々によく書けていると思いましたよ。クレジットカードのデータ流出を起こすとどんな目に遭うのか良く分かるので、同様のシステムを抱えている人にとって参考になると思いますし。
＃私は何年か前にここで購入した事があり、何度か今回の件でメールが届いていました。
＃結果的に私のデータは流出事件の対象外でしたけど。
Re:要するに (スコア:1)
この一文を境に、前と後ろの落差が極端だなぁ。
っつーか２４時間体制のシステム管理はどこに逝ったんだ？
そんな人員が居るなら、ＳＱＬインジェクション知りませんでしたなんていいわけは到底通らないだろうに。
３Ｄなんちゃら導入した結果、安心してシステム管理部門を解散してしまい、後はほったらかしでしたってんなら
それこそ経営責任だと思うけどなぁ。
# ０Dayに対応できませんでしたってんならともかくねぇ。
Re:要するに (スコア:2, おもしろおかしい)
んで気になったのは総論の中のこの一文
>サイバーテロによる破壊の被害にもあいましたがその結果、
>サウンドハウスは今、およそ最強のセキュリティ管理体制を整えつつあります。
なんかまた安心してしまっているような…、気のせい？
Re:要するに (スコア:2, すばらしい洞察)
国防省ぐらいコストをかけているなら最強といってもいいけど、
セキュリティ専門家すらいない低コストで運用している一中小企業が、最強のセキュリティを手にいれられるわけないでしょうが。
せいぜい、現時点で、対処できる施策の中で、コストとリスクを考えた上で、もっともよい施策を選んだ程度でしょ。
Re:要するに (スコア:2, おもしろおかしい)
それが「最強のセキュリティ」じゃないかなぁ、と思う。
#そうであることを祈る。
Re:要するに (スコア:1)
>なんかまた安心してしまっているような…、気のせい？
対応策には「4.プログラムの除去 外部から挿入された疑いが高い不正プログラムの除去を実施。」とあって、OSを入れ替えました、とか、再インストールしました、とは明確に書いてないんですよね。少なくとも任意のシェルコマンドを実行可能だった疑いのある期間があったわけですから、真っ先にそこをどう対策したのか書くべきじゃないのかな、と思います。最強のセキュリティ管理体制が早く整うと良いなぁ、と願うばかりです。
Re:要するに (スコア:1)
なんかこう、情報流出の前段階として何か悲しいことが起きていたんじゃないだろうか。
Re:要するに (スコア:2, おもしろおかしい)
・・・一人三交代とか・・・
・・・社内ひきこもりとか・・・
・・・サーバールームに巣くう巨大な蓑虫とか・・・
・・・昼間社員で夜警備員とか・・・
Re:要するに (スコア:1, すばらしい洞察)
早期対応が遅れた理由もひたすらカード会社からの指示ばかり繰り返しているし。
#JCBの対応の方が鈍いのが面白い。
後半の社長の作文なんて目が滑って流し読みでしたが、泣き言はいいから腹でも切って朽ちろとしか思えないですな＜流出された身としては
なんというか、こういう釈明文はあんまりいい印象を受けないんですが。
みなさんはどうですか？
Re:要するに (スコア:2, 参考になる)
同様の事件でいつも感じる、「なんでこんなに発表遅れるの？」という理由が
しっかり書かれているように思いましたが。
ユーザは一刻も早く情報が欲しいと騒ぐけれど、当事者になってしまうと、
対象が絞れないまま第一報を出してしまったら混乱するという、
当たり前の視点が抜けてしまうんだなぁ、と思いましたよ。
後半を作文と言ってしまうのは簡単ですが、
一般的な企業のセキュリティ意識としてしっかり受け止めることは大切だと思います。
また、セキュリティ製品を売っている方達には、
セキュリティ製品に完全は無いのに、大げさに宣伝した結果、
ユーザが、製品によって解決できる問題と解決できない問題を把握出来ず、
結果、このようなことが起こりうるのだと言うことも、把握することも大事だと思います。
言いつづければ本当になる (スコア:1, すばらしい洞察)
社長は技術的にはあまり詳しく無く、技術があげてくる説明(言い訳と読む)をつなぎ合わせて、詫びとお知らせという文章を作ってしまったということはないでしょうか？
どこの会社でも失敗したときに自分を正当化するためにこういう言い訳をする技術者って、良くいませんか？
いくら苦しい言い訳でも言い続ければ、不思議なもので30%ぐらいは分があると思うようになってしまうものです。
長ったらしい弁明文だけど，気持ちも分からないでもない (スコア:3, 参考になる)
SQLインジェクションに対する脆弱性が判明して，
それを修正した際は，
一からサーバの再構築をしたほうがよい，ってことね。
一応，2006年末にSQLインジェクション対策はしてるみたいだし。
でも，それ以前にバックドアが仕込まれてるので意味がない，と。
個人的には，本当に「2007年以降のデータだけで済んでる？」とは言いたいが，
まあ，完璧なレベルを求めてもしかたないしね・・・
Re:長ったらしい弁明文だけど，気持ちも分からないでもない (スコア:1)
Re:長ったらしい弁明文だけど，気持ちも分からないでもない (スコア:3, すばらしい洞察)
SQLインジェクションだけ？ (スコア:2, 興味深い)
| 例をあげれば、その結果ファイアーウォールによるアクセス制限が甘くなり、
| 弊社のシステム開発を行うスタッフとデータのやり取りを日々実行している内に、
| 拠点のグローバルIPアドレスに対して、SQLサービスのアクセスがインターネットを
| 介して可能な状態になっていました。
え～っと、SQLサービスがフィルタリングされていなかった？
# 「例をあげれば」ってなんだろう...。
Re:SQLインジェクションだけ？ (スコア:3, 参考になる)
お知らせの中に書いてあった「中国のブログ」と思われるものを読みました。
やや不明瞭ですが他のポートも豪快に開いていたように書いていますし、2006年8月24日の段階では、それ以前の問題としてシェルを完全に取られていて、任意のコマンドを実行し放題です。サーバのアカウントの作成方法も丁寧に解説されています。書いた人は自分はアカウントの作成はやってないと言っているようですから、実際当時においても出来たのかは分かりません。でも当然、やってみたんじゃないのかなぁ、と疑わしいものです。
よって、SQLサーバが外に開いていようが閉じていようが、そんなのはもはや非常にささいな事ではないでしょうか。
Re:SQLインジェクションだけ？ (スコア:5, 参考になる)
すでにサイトは無くなっていましたが、Googleのキャッシュや PDF
形式で残っていたので中国語の勉強ついでに翻訳しました。雰囲気
だけでも伝わるかな。
# ちょっと長いけど勘弁してください。
--
日本のウェブサイトへの(一回限りの? )侵入
2006-08-24 16:05:17
ターゲット : http://www.soundhouse.co.jp (日本のサイト)
IPアドレス : 210.143.133.210
(図 1)
□(口偏に阿)D (ツール名)という枯れた方法でインジェクションポ
イントを探すと(すぐに)見つかった。
インジェクションポイント : http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=161^SCX25
(図 2)
NBSI(ツール名)で調べると、sa(system admin)権限のようだ。
(図 3)
Commander (ツール名)でコマンドを実行。
(図 4)
dir C:\ で Cドライブの中身を調べる。
(図 5)
netstat -an コマンドで(そのマシンの)どのポートが開いているか
調べると... よし、3389が開放されている。開いていなかったら、
3389を開放するツールをアップロードして(ポートを)開ければいい。
で、ユーザーを作成してから3389で(その)マシンにログインする。
コマンドは
net user (ユーザー名) (パスワード) /add
net localgroup administrators (ユーザー名) /add
俺は作らなかったけどね。
(図 6)
バックドアを残しておき、 MSSQLというファイルアップロードのセ
キュリティホールを利用したツールでダウンローダー(?) をアップ
ロードする。もちろん、別の方法でアップロードしても構わない。
例えば、スクリプトによるアップロード、 ftpによるアップロード、
tftpによるアップロードなど、方法はたくさんある。ネットにはア
ップロードに関する教えがたくさんあるが... まぁ、あまり細かく
は言うまい。
(図 7)
(図 8)
最後に後始末を忘れないように。後始末のツールとしてよく使われ
るのが阿榕(人名? )の(作成した) LogKiller.exeだ。このツールは
相手(侵入したマシンのユーザー)のログを全て削除できる。ログの
中にはイベントログの「アプリケーション」や「セキュリティ」、
「システム」、 IISの FTPやSMTPサービス、 Webサービスのログは
言うに及ばず、スケジュールされたタスクのログといったものも含
まれる。
また、自分で以下のようなバッチを書いてもいい。
@del %SystemRoot%\system32\logfiles*.*
@del %SystemRoot%\system32\config*.evt
@del %SystemRoot%\system32\dtclog*.*
@del %SystemRoot%\system32\*.log
@del %SystemRoot%\system32\*.txt
@del %SystemRoot%\*.txt
@del %SystemRoot%\*.log
@del del.bat
興味のある奴はそのまま(システム内部に)溶け込んで、 Webサーバ
ーのルートディレクトリや日本のサイトを探してみよう www
新参は(ここを)見ながらやってみるといい、古参はコメント大歓迎。
インジェクションポイントは変えないでね。(その方が)新参が勉強
するのに都合がいいから。
# When humans are connected, small voices will become larger.
Re:SQLインジェクションだけ？ (スコア:2, 参考になる)
これは [mop.com] 復活してるのだろうか？それともキャッシュを見てる？
自力で見つけたんではなく、元コメントの中から適当にキーワードを選んでググったんですが。
図が見えるので、それなりに参考になろうかと。
Re:SQLインジェクションだけ？ (スコア:1)
私はその「中国のブログ」とやらを探す気力はありませんでした。(^_^;;
確かに例示されたフィルタリング云々は些細な事でしょう。
ですがその些細な事を例示して誤魔化しているように感じました。
だって、「開発拠点に対してフィルタが緩かった」と言われたら、
「それ以外へのフィルタは有効になっていた」と誤認しませんかね？
# ま、そもそも開発拠点からDBアクセスしていた可能性があるってことは、
# ネット上を暗号化されない平文データが流れてたんだろうなぁ、と
# 推測できてしまいますが。
Re:SQLインジェクションだけ？ (スコア:1)
索したところ、これかなと思われる方法は見つかりました。
でも、
> 「中国のブログ」と思われるものを読みました。
はなかなか見つからない。
# 読んでみたい...
# When humans are connected, small voices will become larger.
Re:SQLインジェクションだけ？ (スコア:1)
いいけど (スコア:2, すばらしい洞察)
ハッキングじゃなくて、クラッキング
と書いてくれ＞PDF文書
他の脆弱性 (スコア:2, 参考になる)
先生、質問！ (スコア:1)
４ページ目の17:50のところ。
>LACのアドバイスにより、お客様へニュース配信する前に、クレジットカード会社に、その旨、告知が必要
ってあるんだけど、告知が必要な理由って何です？
「クレジット情報がもれた可能性があり、調査中です」って告知も出せないのだろうか？
Re:先生、質問！ (スコア:1)
10ページ目に
>3月22日に、もしニュースをリリースしたとするなら、それこそ大混乱に
ってあります。
これは
1.社長がそう思っている
2.LACがそう言ったのを社長がここに書いた。
3.カード会社がそう言ったのを社長がここに書いた。
どれなんでしょう？
あと、別に大混乱が起こっても、早めに情報公開してほしい。
と思うんですがどうなのでしょう？
Re:先生、質問！ (スコア:2, 興味深い)
よって止めたのもカード会社であり、カード会社及び事故処理をよく知るLAC。と読み取りました
カード会社としては苦情・相談受付の人員確保の時間を稼ぎたかったのでしょう。
Re:先生、質問！ (スコア:2, すばらしい洞察)
そんな後ろ向きな理由じゃなくてもね、いくら人数を確保したところでどんな受け答えができるというんですか？ よくわからなくてもいいから知らせてほしいと言った人は問い合わせをして「現在調査中です」って返事を聞いて納得する？たぶん聞いたら怒るんじゃない？だとしたら、きちんとした情報を得てから公表するほうが無駄なやり取りがない分いいんじゃないのかな。
Re:先生、質問！ (スコア:1, 興味深い)
不完全な情報しか提供できないと、デマが蔓延して恐ろしい事になる可能性ががが
むしろ、カード会社はこちらを恐れたんでないかと。
時系列レポート (スコア:1, すばらしい洞察)
当たり前のことかもしれないけど、きちんと出来ているところは少ないのではないでしょうか？
24時間体制のシステム管理者 (スコア:1, すばらしい洞察)
カード決済なんだけど (スコア:1, 参考になる)
手数料？
そっちと契約し直せば（カード会社の審査が通るかわからんが）、
カード決済できるんではなかろうか。
Re:長ぇ (スコア:1, すばらしい洞察)
ネタと教訓の宝庫だ。
Re:効果的な対策 (スコア:1, 興味深い)
ウチでは不正中継しようとするメールがかなり減りました。
# よく出てくるけどうざい国からのアクセスを全て遮断 [42ch.net]。
# ↑これを実装して、定期的にフィルタをアップデートしてくれるハードウェアファイアーウォールとか、どこか作ってくれないかなぁ。
Re:効果的な対策 (スコア:2, おもしろおかしい)
ボクならいいですか？
Re:.asp系 な環境の事故 (スコア:3, すばらしい洞察)
Re:.asp系 な環境の事故 (スコア:2, 参考になる)
> ◇SE・プログラマー
> サウンドハウスのシステムはすべて自社開発。物流、インターネット販売システムを自らの手でデザインする夢を持っている方、大歓迎！
> Visuai Basic、SQL Serverを使用してのプログラミング。経験3年以上のプログラマー優遇します。
だそうで。
今回の件に関して言えば、VB6の知識で停滞してるクラサバオンリーの開発者に作らせたらASPになった、とかじゃないでしょうか。
VBScriptならレガシーVBの経験がそこそこ使える（ように見えてしまう）し。
本格的に通販サイトとしてサイトリニューアルした時期にASP.NETがあったかどうか微妙だけど、
そこで勉強し直してASP.NETで作っていたら、セキュリティにもっと気をつけることができたんじゃないかなぁという気はします。
もちろん、クラックのターゲットとして、ASPで動いている通販サイトが狙われやすいという話もありますけどね。
狙われやすい理由は上述のようなパターンが多いからかもしれませんが。
Re:斜め読みしましたが (スコア:2, 参考になる)
一般的に、カード決済を(自前で)行う場合、カード会社との加盟店契約で、カード利用者からの問合せ対応のため、一定期間カード番号を含めたトランザクション情報の保持が求められます。もちろん、別スレッドでどなたかが指摘されていたように、決済代行会社を利用する、という手段はとりうるのですが。