hsgw先生のXMLHttpRequestを使ったCSRF対策について

http://d.hatena.ne.jp/hasegawayosuke/20130302/p1

について

サーバ側でセッション管理せずに済むというメリットはでかくていいですね。
ログインの有無も関係なくなるのでカクイイです。
これからの時代はこういうのが主流になるべきという気がします。

デメリットですが
・JavaScript必須(hsgw先生が書いているとおり)
・画面遷移に影響が出る。普通のPOSTと違うので、アプリの挙動に影響がある
・古いブラウザでは動かない

という感じでしょうか。

追記:
var s =
encodeURIComponent( document.getElementById(“mail”).value ) + “&” +
encodeURIComponent( document.getElementById(“msg”).value );

みたいに自分でフォームのデータを生成する手間がそびえたつクソですね(;´Д`)
まぁ、ライブラリ化すればいいんでしょうが、そこに変なバグとか入ってきたりすると萎えるかも。

(追記)
値の名前(mailとか)が入っていないというバグが入っていたようです(;´Д`)ゴラァ
『古いブラウザ』って何?ってhsgw先生に怒られたんですが、もちろんNetscape Communicator 4系列とかです(;´Д`)

Advertisements

5 Comments on “hsgw先生のXMLHttpRequestを使ったCSRF対策について”

  1. hsj says:

    jQueryとか使って、サーバ側でX-Requested-Withヘッダをチェックする様に
    してるのはたまに見る形ですね。
    ただ、昔のFlashPlayerみたいに任意のヘッダが送信出来ちゃうとか、
    そう言う問題へのfail-safeまで考えると、当方としては基本的には
    普通の方法での対策を推奨する様にしております・・・。

    もっとも、現代的にはその手の話も枯れてきて今さら新たに問題として
    出てくる可能性も低いでしょうから、そろそろこれでOKとしても
    良いのかもしれませんねヽ(´ー`)ノ

  2. 金床 says:

    なるへそ。

    …Javaアプレットとかも(HTTPヘッダに任意のフィールド追加できるのかどうか)調べないとダメですね(;´Д`)

  3. 金床 says:

    ていうかDNS Rebindingで回避できるカモ(;´Д`)

  4. hsj says:

    ツイッタ界隈は進行が速いですねヽ(;´ー`)ノ

    言葉が足りませんでしたが、古いFlashPlayerは単に過去の実例として挙げただけで、
    主には今後同じ様な問題が出てきた場合の為のfail-safeと言う意味ですので・・・。
    2011年当時の307リダイレクトの話なんかは、まさにその手の問題ですね。

    それはそれとして、クソ環境のユーザの事なんて考えてもしょうがなくね?と言うのは、
    ユーザを守ると言う視点ではその通りですね。
    ただ、前コメントでの視点は、ぶっちゃけユーザを守りたいではなく、合理的な範囲でなら
    webサイト側には過失が無い様にしたい、と言うモノですヽ(;´ー`)ノ
    #一方の目的で対策したら、結果的に他方の対策にもなると言う場合も多いですけども
    何と言うか、webサイトを運営する場合に、ユーザのPCに乗っ取りを許す脆弱性が云々とかまで
    心配してもしょうがないですが、それと自サイトが最近流行の水飲み場にならない様に
    運用する事とは別問題、と言うのと似た様な物でしょうかヽ(;´ー`)ノ

    ところでこの話題は、CSRFで犯行予告を行わされてしまう事にどう対処するか?と言う話からの
    流れだと認識していますが、個人的なスタンスとしては、ネット経由での犯行予告になんて
    マジになんなよヽ(´ー`)ノです。ワラ
    特に、いつぞやのコウナゴの件の様な、エクストリーム犯行予告なんかには笑ってスルーできる余裕が
    欲しいですね。

    と、チャブ台ひっくり返しっぱなのもアレなので、クッキーモンスターの件を少し考えてみましたが、XHRでの
    カスタムヘッダ付きリクエストにトークンも渡す、あるいは、トークンとIPアドレスとを紐付けておき、
    入力確定処理時にチェックを行う、ただしこれでエラーになった場合トークンを発行し直し、
    ユーザ入力と共に目立つ警告付きで入力画面(あるいは確認画面を挟む場合は確認画面)に戻す、
    とかでどうでしょうね?
    #それとも、IPアドレスってこの程度も許容できないくらいパカパカ変わる事もあったりするでしょうか?

    ・・・どっちにせよ、実にバッドノウハウ臭が漂っててアレな感じではありますが(;´Д`)

    • 金床 says:

      fail-safe的なのって議論するのが難しいですよね。
      XSSがあったら?とか盗聴されてたら?とか気にし出すときりがないし…
      でもまぁ、XHRのヘッダだけに頼る方法はシンプルなだけに、何かしらのきっかけ(プラグイン系のバグとか)で突破されがちになりそうな予感はします。

      > 個人的なスタンスとしては、ネット経由での犯行予告になんて
      > マジになんなよヽ(´ー`)ノです。ワラ

      マジで同意ですね〜
      ドクロがボゥボゥ燃えながら回転してる頃のインターネットに戻りたいでつw

      > あるいは、トークンとIPアドレスとを紐付けておき、
      ↑をやるかやらないかは大きな分かれ目でしょうね。
      IPアドレス変化するやつには書き込ませない キリッ
      とかだと結構強固になる気がします。

      …っていうか、ドメイン変えろっていう話ですが(;´Д`)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s