トップ «前の日記(2006/03/30(Thu)) 最新次の日記(2006/04/01(Sat))» 編集

糸の切れた凧(たこ)　（　a threadless kite　）

ここは、管理人yamagataが方針未定のまま、何となーく思いついたことを思いついたままにだらだらと書き付ける日記帳です。ふんわりほんわかな感じでお願いします。

2006/03/31(Fri) 金曜日ー。（取り残されていく。。。）

■ [占い] 交通違反占い

あなたのタイプは「酒気帯び運転」です。
酒が好きで、酒に溺れがちなタイプ。ストレスがたまっていると、ついついアルコールに手が伸びてしまいそう。また人の言うことを断るのが下手なのもこのタイプの特長。車で来ているのに、まぁ飲めと言われるとついつい飲んでしまうようです。キッパリと断るよう心がけましょう。

なんちゅう占いだｗ　ちなみに、私、お酒を飲んで運転したことは一度もありませんよ！（それ以前に、最後に車に触ったのは、・・・教習所の卒業検定の時なんですがｗ）

■ [雑談] アキバで大人気の仕込竹箒って一体？ (ExciteBit)

杖みたいにいつも持っているものに仕込むなら良いけど、ホウキってｗ

■ [セキュリティ] 開発者のための正しいCSRF対策 (金床さん)

CSSXSS対策も盛り込んだため、リクエスト1がPOST限定（GETにしたい場合はCookieからJavaScriptで値をセットする）で、リクエスト2はPOSTでもGETでも良いという、一見、今までの定説とは逆のようなイメージになるのね〜。
CAPTCHAは、確かに結果的にCSRF対策になると思いますが、これをCSRF対策として押すのはどうかなとも思ったりも。
リファラーによる対策は、確かに通常のサイトでは採用しにくいと思います。（2chがこの方式を採用できたのは、サイト側の力が利用者側より強い特殊事情のお陰ですものね。一般の商用サイトでは...）（他の手段による対策を施した上で、保険として、リファラが送られてきた場合にはそれが自サイトかチェックする機構を実装するのは良いかも知れない。）
「セッションIDをトークンとして使う」のところで、『リクエスト2は必ずPOSTである必要がある。高木氏のページをはじめ多くのページではこのことが明記されていない。』と書かれていますが、高木先生の「安全なWebアプリ開発の鉄則2004」の52ページや、「情報セキュリティ白書 2006年版」の59ページなど、ちゃんと記述があるように見えます。
『誤った対策その1: セッションIDをトークンとして使う』を“誤った対策”と言い切ってしまうのはどうかなぁ。あくまでも、ブラウザの脆弱性（CSSXSS対策）も一緒に盛り込もうと思った時には意味を成さないということで、CSRF対策としては間違っていませんから。
CSSXSS対策のようなブラウザの脆弱性への対策を盛り込むのは、例えば、趣味のサイトをこれから作る友人にアドバイスするという状況であれば、迷わず「こんなんあるよ〜」と話に出しますが、IPA や何かから公開する文書に記述するのは難しいのだろうなとも思いますね。確かに、9割のユーザが助かるのなら、とも思いますが、自社開発でない商用のサイトで IE のバグが出るたびに予算を採って修正するわけにもいかないと思いますし、この文書で説明されてるCSSXSS対策が今後仇となるようなブラウザのバグが出てこないとも限らないですしね。