パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ACCS個人情報流出事件でACCS側のインタビュー」記事へのコメント

  • by Anonymous Coward on 2004年03月20日 1時51分 (#517900)
    ちょっとマジレスしていいかな。

    たしかにACCSはもう少し注意することができたかもしれない。だけどね、officeがアクセスしなければ漏洩は始めから存在しないのだよ。

    不正にアクセスしなけりゃいいんじゃないのか?

    ガチガチにセキュリティをかけるには何百万円もかかる。そんなの小さい団体に出せるわけがないじゃないか。もっと現実を見てほしい。

    • by __hage (7886) on 2004年03月20日 3時37分 (#517947)
      というところまでで思考が止まっちゃう素朴な一般人相手に対して
      ごまかした発言をしてるところに卑怯さを感じますね、ACCSには。

      office氏=盗んでばらまいた悪いやつ
      ACCS=盗まれたかわいそうな団体

      がおおまかな世間一般の評価でしょうから。

      # 前者には、わたしはさほど異論がありません。

      それでここで問題になってるのは後者であるわけですよ。
      その発言のおかしなところを容易に見抜かれてここでは批判が集中してます。

      >ガチガチにセキュリティをかけるには何百万円もかかる。
      >そんなの小さい団体に出せるわけがないじゃないか。
      >もっと現実を見てほしい。

      その後には何が続くんでしょうか。
      「だから対策をしなくてもいい」でしょうか。
      サブジェクトからいうとそう言いたげな気もします。

      であるならばACCSの発言にミスリードされちゃってますね。
      ACCSの発言はこういう風に騙すのを目的とした卑怯な発言としか思えません。

      もしコストがかかりすぎて対策が取れないというのが本当であれば、
      個人情報を扱う資格などありません。
      現実を見るならば個人情報を扱うべきではないでしょう。
      というのが、少なくとも他人様の情報を扱う側に求められる態度ではありませんか?

      とにかく無知につけ込んで保身を図る発言には反吐が出ます。
      親コメント
    • 煽りコメントが俺を呼ぶ。マジレスマン参上。

      office氏がアクセスしていない場合にしても、それまでにACCS側から情報が漏洩
      していないことを証明することはできない。
      (取得した人間が黙っている場合、それこそわかりようがない)
      むしろ、「杜撰な管理をされていた」こと自体がすなわち「情報は漏洩していた」
      と見られても致し方ないと言える。
      ACCSの責任問題に言及するならば、個人情報の扱い方の杜撰さを指摘することが
      第一であって、それを実際に取りに行った/行かないことを混ぜてしまうと、
      それこそ文字どおりクソミソである。(ウホッ…ではない)

      「不正にアクセスしなければいい」の件については確かにそのとおりであるが、
      まずは「何が不正で、何が不正でないか」を切り分けないと、そもそも「不正」の
      定義ができないのだよ。

      今回の事件、確かにofficeは不正であった。
      ACCSは、office氏が間違っていた分だけ正しい。
      しかし、それだけだ。
      個人情報を杜撰に管理していたことは、全く別のレイヤーの話だ。

      ガチガチにセキュリティを…の件に関しては、上の(#517842) [srad.jp]で
      よく解説されていると判断される。御一読されるとよろしかろう。
      --
      (∑´w`)キョウモ マジレス
      親コメント
    • by Anonymous Coward on 2004年03月20日 21時17分 (#518249)
      現実を見てといわれたので現実を見ると。

      残念なことに世の中善人ばかりじゃない。悪人もいるので警察や法律や裁判所がある。ネットもそれが必要になったということだろう。

      守るべき資産の価値が大きいほど防犯意識は高い方がいい。首相などVIPには護衛がつく。1000円しか入ってない財布は落としてもそれほど困らないが、キャッシュカード・クレジットカード・運転免許証が入っているなら1000円の時よりは気をつけるし、給料をおろした金が入っているなら相当気をつけるはず。

      人のものを預かっているならより一層セキュリティには気をつけなければならない。護衛がむざむざとVIPを暗殺されたとき相手が凄腕だったのででは言い訳にならないし、銀行の貸し金庫や預金もそう。人から借りた本やCDは大切に扱ってもし無くしたらせめて買って返すはず。受けている信頼を失わないためにはそれを守らなきゃいけない。信頼そのものは貨幣換算できないが、それを失えば結果として金も失うだろう。

      私は、法的な責任なら守るが個人情報を預かるサイトが果たすべき信頼を守る義務はないと暗に言っている ACCS を信頼しないことにしました。
      親コメント
      • 私は、法的な責任なら守るが個人情報を預かるサイトが果たすべき信頼を守る義務はないと暗に言っている ACCS を信頼しないことにしました。

        そうしていただいても、ACCSにとっては何ら痛くない。なぜなら、個人からの信頼を得ることは目的外という性質の組織だから。

        それはACCSの自由だと思うが、問題は、今回の久保田専務理事の発言は、その態度を他の一般企業にまで広げて適用されて当然との考えを示していることだ。以下の部分

    • >不正にアクセスしなけりゃいいんじゃないのか?

      国外からの不正アクセスにはどう対処するの?
    • そもそも管理できないなら個人情報を収集すべきではない。
    • 実際に盗む奴が居たから問題になってるんですよ
      事実と反する仮定には意味がありません
    • じゃあお尋ねするが、 あなたは不正にコピーされたとき自分で気付けるのですか?

      ファイル名を指定しただけでダウンロードできてしまうような超初歩的な欠陥に気付かなかったようなところが、自分で不正コピーに気付けるのですか?

      直近の情報がすべて記録されているファイルが存在することはないと認識しておりましたが、フォルダ内を調べたところ該当するファイルを確認し

      とかいう、全く何も気を遣っていなかったような人たちが、自分で不正コピーに気

      • >ファイル名を指定しただけでダウンロードできてしまうような超初歩的な欠陥

        実際にはそんな簡単な欠陥ではないのですが、そういうことにしておきたい人が山のようにいますねぇ(w
        • じゃ、どんなムズカシイことしたのか言えるのかな?(クスクス
        • > 実際にはそんな簡単な欠陥ではないのですが

          実際にそんな簡単な欠陥でしたよ。

          エステやらとの違いは、ファイル名を指定する場所がヘッダじゃなくてボディだったというだけ。

          まあ、あんたにはヘッダとかボディつーても意味がわからんのだろうけどな。意味わからんやつがしゃべることは総じて罪。
          • >エステやらとの違いは、ファイル名を指定する場所がヘッダじゃなくてボディだったというだけ


            なんだ、わけもわからずに書いてるだけか。
            •  ヘッダじゃなくてボディだった、で正解ですね。

               エステの流出は GET でパラメータを送って取ったけど、この場合は POST のパラメータを送って取った。
               それだけの違いしかないですよ。

               httpのGETメソッドのリクエストは
              GET /directory/file HTTP/1.0
              (空行)
               で、POSTメソッドのリクエストは
              POST /directory/file HTTP/1.0
              Content-Length: 10
              (空行)
              Data-part.

               となっています。なお、空行で区切られてる部分までを「ヘッダ」と呼ぶわけです。
               さて、「わけもわから」ないのはどっちでしょう?
              親コメント
              • ・GET とか POST とかを指定する、Requestの最初の1行は Request-Line であって、Header ではありません。(2行目以降、空行までがHeaderです)

                ・たいていの CGI は、POST でも GET でも同じ引数を指定すれば、同じ動作をします。
                ですから、POST か GET かというのは本質的には違いはありません。
                親コメント
              • >それだけの違いしかないですよ。

                話にならん、テンプレ [geocities.jp]でも読んで出直して来い。
                なんで思い込みだけでぐだぐだ語りたがるんだろうなぁ、ったく。
              •  これは失礼。1行め(Start-Line)はheaderに含まないんですね。
                 ところで、今回問題になっているcgiはPOSTでしか問題の動作をしないものだったという話を聞きましたが、その辺はどうでしょうか?
                親コメント
              •  当然読んでますが。
                 そのサイトの中の、
                ■office氏はどんな方法で個人情報にアクセスしたの?
                [geocities.jp]に、私が書いたのと同じ内容がありますよ?
                親コメント
              • by Anonymous Coward on 2004年03月21日 10時40分 (#518453)
                ・たいていの CGI は、POST でも GET でも同じ引数を指定すれば、同じ動作をします。
                ですから、POST か GET かというのは本質的には違いはありません。


                のような事を平気で言うヤツが作るCGIスクリプト/プログラムが危ないのだよね、実際。リクエストメソッド(やリクエストヘッダ)をチェックしないで処理してる、って事じゃない、それはさ。
                親コメント
              • > リクエストメソッド(やリクエストヘッダ)をチェックしないで処理してる、って事じゃない、それはさ。

                セキュリティ上の観点からGETかPOSTかは厳密に区別しろ、という話であれば、そういう意見があることはわかりますが、

                perl で cgi を作るのだったら、普通は CGI.pm とか CGI::Lite.pm を使って、そのあたりのことは意識しないようにするものだと思うのですが…
                親コメント
              • > のような事を平気で言うヤツが作るCGIスクリプト/プログラムが危ないのだよね、実際。リクエストメソッド(やリクエストヘッダ)をチェックしないで

                メソッドをPOSTにさえしておけば十分に堅牢になったとでも?
                このケースでは堅牢さにおいては全く変わりないですよ。
                無論、メソッドをPOSTだけにしておきたいならそのほうが良いですが。
                (ところで、ACCSのくだんのCGIはoffice氏の登攀ルートではPOSTしか許してはいませんでした。別ルートがあってGETで可能であったかもしれなかったけれども調べてはいないとoffice氏が言っていたことを思い出しました。)
              • 専用のツールを作るしかないとしたらちょっとやそっとでマネする人はなかなかいなかったんじゃぁないかな。

                そんなもん、ツールなんていらない。ブラウザすらいらない。telnet するだけ。

                telnet www.example.com 80
                ...
                POST /cgi-bin/foo.cgi
                Referer: http://www.example.com/foo.html

                filename=/usr/data/foo.csv

                セーブし、エディタで修正し、そこからPOSTしたわけです。

              • perl で cgi を作るのだったら、普通は CGI.pm とか CGI::Lite.pm を使って、そのあたりのことは意識しないようにするものだと思うのですが…

                CGI.pmとかが、たまたまリクエストメソッドの違いを見せない実装になっているだけの話なんだよね。あまり分かってない素人衆には、小難しい事が隠れているそういう実装はありがたいだろうとは思うよ。けど、CGI.pmを生で使ってそれだけ、CGI.pmの実装がどうなっているかは気にならない、というのは、それだけのレベルでしかないんだよね。

                GETとPOSTでは制約の条件が明らかに違うし。GETで十万バイト位のフォームデ
              • >POST /cgi-bin/foo.cgi
                >Referer: http://www.example.com/foo.html
                >
                >filename=/usr/data/foo.csv

                 うーん。Content-lengthとエンティティボディの実際の長さ位はチェックしないかしら。最近はそういう面倒臭いチェックとかは、しないものなのかしらん。

                >それがわかってない奴は、お願いだから、セキュリティが
                >求められる仕事にたずさわらないでくれ。

                 これは同感。尻拭いが大変でねえ。首にすれば簡単なんだけど、そうは行かない場合もあって。
                親コメント
              • perl で cgi を作るのだったら、普通は CGI.pm とか CGI::Lite.pm を使って、そのあたりのことは意識しないようにするものだと思うのですが…

                普通は、その上で request_method() メソッドとか使って POST だけを許可とかやりませんか? ポリシーに応じて。

                親コメント
    • 泥棒がいなければ鍵や警察のコストも(ry

      ACCS 側の言い分を鵜呑みにしすぎです。
      ちゃんと事実関係把握してますか?何があったのか、脆弱性の内容や経緯を人に説明できますか?反論かける前にそれくらい調べろよ、と。
    • 情報を漏洩された被害者にもそう言ってくれ

      個人情報を管理・保護しなければならないにもかかわらず,その意識も技術も無い(若しくは極めて低い),個人情報を収集している者達には自分の視点しかないのか....

      実はそんなところに情報を提供しているユーザが悪いとかいうことかな(・∀・;)?
    • とACCSは言っている、とまで書かないと誤解されますよ
    • おいらは今日業務でやってたやつにPHPだからaddslashesかけまくったが、何百万ももらっちゃいないよ。
    • >不正にアクセスしなけりゃいいんじゃないのか?

      不正アクセスではないと思うぞ。
      ACCSは不正アクセスってことにしたいだろうけど。
    • ところで、今回の件、仮にoffice氏がファイルをさらさなかったとして、不正アクセス禁止法にはひっかかるんでしょうか?

      パスワードなどで保護された情報やコンピュータに自分に与えられたのではないパスワードを使
      • 今回の件、仮にoffice氏がファイルをさらさなかったとして、不正アクセス禁止法にはひっかかるんでしょうか?

        ファイルを晒すことが無関係であることは、法律を読めばわかることです。
        先日立件された、模倣犯3名はファイルを晒していないのでしょうし。

        パスワードなどで保護された情報やコンピュータに自分に与えられたのではないパスワードを使用してアクセスするとひっかかるけ

ソースを見ろ -- ある4桁UID

処理中...