ふたつの川うるおう日記

_ [Java] Cross-Site Request Forgeries対策 なるほどなるほど

いろいろ奥が深いみたいですね。何個かサイト見てみたらセッションIDを生でそのまま使うのは精神衛生上良い方法ではないかも。

• 参考サイト
  • 高木浩光＠自宅の日記 しばらく日記をちゃんと書けそうにない
  • おさかなラボ hiddenにセッションIDを埋めるのは本当に安全なのか
  • おおいわのこめんと hidden field に session ID を入れる CSRF 対策方法に対する反論に対する反論

というわけで、次のどちらかに変えようかな。

1. セッションIDをSHAかSSHAハッシュしたのをhiddenに仕込んで使う
2. おさかなラボのクロスサイトリクエストフォージェリ対策をCSRF対策するページごとに異なるキーで持つ

たぶん2つ目の方がより安全なんだろうけど、この方法の場合ページにアクセスするごとにキーが変わっちゃうので、タブブラウザで複数開いて、やっぱ消して最初のとこで入れようとするとキーが変わっちゃっててアウトになっちゃったりする。無意味にリンクをクリックしてタブを開きまくる僕的にそれは嫌だなーってことで、1に落ち着きそう。SSLなサイトならProxy挟んでも暗号化されてキャッシュとして使える形で残らないだろうし。 一応2に書いたようにページ単位でセッション持つキー名を変えれば、同じページを何個も開くという可能性は減るからやるならそれで。

まぁどっちにしてもS2Directoryのcryptパッケージが生かせて満足(゜ー゜)。

昔作ったWEBアプリにはCSRF対策なんかして無かったなー。

今回の2みたいなのだけでなく、いろんなWEBアプリ使う上でリンクをクリックして別タブでページを開いていって、その時にセッションの値を上書きしていってしまいタブを閉じて元に戻った時にそこにあるフォームやリンクが使えなくなってしまっている状態になるWEBアプリは嫌いです。理由はさっきと同じ。だからWEBアプリのフレームワークでもセッション使わないで簡単に書けるようになってないとあんまり好きじゃないです。

あ、上記はログイン処理で上書きしていくのはもちろんアリです。ログイン後の機能を提供する画面でそうなってるのがアウト。違いはログインは通常1度しか通らない一方通行の入り口であるのに対して、ログイン後の機能は何回もそこを通る可能性がある空間であるかです。

| Bookmark:

_ [大学] 修論のプレゼン資料出来た

うーん、オーバーしそう。。練習しながら考えよう。

1日期限間違えてた罠。

| Bookmark: