パスワードを忘れた? アカウント作成
398327 journal

yoshitakeの日記: はずかしぃ>< 5

日記 by yoshitake

CSRFって言葉しらなかった。。。
もしかして常識?
んー。
今まで作ったもの全般的に見直さないとなぁ。。。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by roiko (29243) on 2006年04月12日 0時05分 (#919465)
    ごく一部の人たちだと思うぞ。一瞬「はまちちゃん」で騒がれたけど、すぐ対応されてしまったし。 でも診断屋としては歓迎なんだけどね、こういう新しい手口は。定期的な診断も強く訴えられるので。
    • でもま、ちょっと考えればありえるパターンでもあっ他訳で。
      せめてXSSで騒がれた時に気付けよ。
      っていう問題な気がする。
      まだまだ注意力たらんなぁ。おれ。
      • んで対策方法。

        1.PHPのセッション情報を「session.use_cookies=0」にして、GetまたはPostにて自動で保持。
        2.CookieにはKAHOのLoginモジュールにて全く別のセッションIDを付与(セッションの変数として保持)。
        3.この両方が合致した場合のみ、アクセスを許す。合致しない場合はセッションそのものを破棄&GC実行

        でどうだろうか。。。。
        これならサイトの設計見直さなくても対策できるんだけど、大事な本来のセッションIDをGetで渡して大丈夫?っていう心配もあったり。
        可能なら、output_bufferを自前で組んで、KAHO用SIDを埋め込むのが良いんだろうけど、パフォーマンスの問題もあるからなぁ。
        ま、XSS対策がきちんとされてれば問題無いか。

        本当はセッションジャックの対策も含めてIPでのチェックも入れたいんだけど、携帯だとIP変わる事あるからなぁ。

        ムズカシィ。
        親コメント
        • あ、だめだ。
          例えば、掲示版等でHPのURLを表示するような所の場合に「session.use_cookies=0」にしておくと勝手にセッションID書かれてしまう。。。
          これじゃ攻撃元にてセッションIDばればれだし、動的ページにして読み取られたら同じ事。。。
          ってか、XSSの元々の問題と同じやん(^^;。XSSの穴作る事になってしまふ。

          うーーーーん。
          やっぱ、サイト設計の時点で考慮していないとだめか?
          もしくは、output_handler書くしか。。。
          なんとかシステマチックに対応できないかなぁ。
          親コメント
          • と思って試してみたら、http〜で始まるリンクや、JavaScriptでのリンク(location.href等)ではSID付加されないのね。
            いちお、PHP側でも考えられているんだなぁ。と(w
            これなら何とかなるかなぁ。
            JavaScript部分だけSID書き出すように替えれば良いんだもんね。

            どうおもふ?
            親コメント
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...