アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
もうあきた (スコア:2, 参考になる)
とは言ってられないはずなんだけどこれだけ続くともうねぇ
企業側の対応もおざなりになってきたみたいだし、顧客も
またかぁで終わる感じですね、最近は
#慣れちゃいけない・・慣れちゃいけない・・慣れちゃいけないんだ！！よね？
あきた？ (スコア:5, 参考になる)
業務ミスという点では らでぃっしゅぼーや [security-next.com]とかザイオン [impress.co.jp]の事例があったけど数字的には穏やか。
今回は、アクセス可能な状態にあった「だけ」ではなく、実際アクセスされていた件数 [impress.co.jp]であるのが大変だなあ。
企業ページで用意しているnamazuなんかでも、「パスワード」とか「bak」とか探すとマズいものがヒットする事が結構あるらしいから
忘れてない？ (スコア:4, 参考になる)
丸善は？
http://internet.watch.impress.co.jp/cda/news/2007/10/29/17326.html [impress.co.jp]
規模も質も最悪クラスだと思うのだが、あまり騒がれていないんだよね。
# 丸善のリリース、「紛失した可能性」って、どう見ても紛失なんだけどwww
Re: (スコア:0)
丸善は企業サイトのトップに2度ほど告知を出していますがNTT Comはだんまりです。
丸善が発表したからよしとするんでしょうか。
業務委託を受けている中での事故ということでNComの責任はかなり重いと思うのですが。
Re: (スコア:0)
TBCの件の詳細は、今回と同様に設定ミスによる不用意なWeb上での公開だった。
SQLインジェクションに注意を払っている部門と、アクセス権wを注意深く管理する部門は、
大抵同じか限りなく近い関係にあるでしょう。
アプリケーションセキュリティは近年注目されているけど、インフラが御座なりになっている、
そこに主題が置かれた話なのに、ただ情報の量と質にしか目が向かないのはあまりに読解力不足。
情報の数とか質だけ問題にしているなら、大日 [atmarkit.co.jp]