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

tech 1 Minute

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系列とかです(;´Д`)

Published by kanatoko

Published

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

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

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

    Reply

  2. なるへそ。

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

    Reply

  4. ﾂｲｯﾀ界隈は進行が速いですねヽ(;´ー`)ノ

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

    それはそれとして、ｸｿ環境のﾕｰｻﾞの事なんて考えてもしょうがなくね？と言うのは、
    ﾕｰｻﾞを守ると言う視点ではその通りですね。
    ただ、前ｺﾒﾝﾄでの視点は、ぶっちゃけﾕｰｻﾞを守りたいではなく、合理的な範囲でなら
    webｻｲﾄ側には過失が無い様にしたい、と言うﾓﾉですヽ(;´ー`)ノ
    ＃一方の目的で対策したら、結果的に他方の対策にもなると言う場合も多いですけども
    何と言うか、webｻｲﾄを運営する場合に、ﾕｰｻﾞのPCに乗っ取りを許す脆弱性が云々とかまで
    心配してもしょうがないですが、それと自ｻｲﾄが最近流行の水飲み場にならない様に
    運用する事とは別問題、と言うのと似た様な物でしょうかヽ(;´ー`)ノ

    ところでこの話題は、CSRFで犯行予告を行わされてしまう事にどう対処するか？と言う話からの
    流れだと認識していますが、個人的なｽﾀﾝｽとしては、ﾈｯﾄ経由での犯行予告になんて
    ﾏｼﾞになんなよヽ(´ー｀)ノです。ﾜﾗ
    特に、いつぞやのｺｳﾅｺﾞの件の様な、ｴｸｽﾄﾘｰﾑ犯行予告なんかには笑ってｽﾙｰできる余裕が
    欲しいですね。

    と、ﾁｬﾌﾞ台ひっくり返しっぱなのもｱﾚなので、ｸｯｷｰﾓﾝｽﾀｰの件を少し考えてみましたが、XHRでの
    ｶｽﾀﾑﾍｯﾀﾞ付きﾘｸｴｽﾄにﾄｰｸﾝも渡す、あるいは、ﾄｰｸﾝとIPｱﾄﾞﾚｽとを紐付けておき、
    入力確定処理時にﾁｪｯｸを行う、ただしこれでｴﾗｰになった場合ﾄｰｸﾝを発行し直し、
    ﾕｰｻﾞ入力と共に目立つ警告付きで入力画面(あるいは確認画面を挟む場合は確認画面)に戻す、
    とかでどうでしょうね？
    ＃それとも、IPｱﾄﾞﾚｽってこの程度も許容できないくらいﾊﾟｶﾊﾟｶ変わる事もあったりするでしょうか？

    ・・・どっちにせよ、実にﾊﾞｯﾄﾞﾉｳﾊｳ臭が漂っててｱﾚな感じではありますが(;´Д`)

    Reply

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

      > 個人的なｽﾀﾝｽとしては、ﾈｯﾄ経由での犯行予告になんて
      > ﾏｼﾞになんなよヽ(´ー｀)ノです。ﾜﾗ

      ﾏｼﾞで同意ですね〜
      ﾄﾞｸﾛがﾎﾞｩﾎﾞｩ燃えながら回転してる頃のｲﾝﾀｰﾈｯﾄに戻りたいでつｗ

      > あるいは、ﾄｰｸﾝとIPｱﾄﾞﾚｽとを紐付けておき、
      ↑をやるかやらないかは大きな分かれ目でしょうね。
      IPｱﾄﾞﾚｽ変化するやつには書き込ませない　ｷﾘｯ
      とかだと結構強固になる気がします。

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

      Reply

Leave a comment