v('ω')v StyleJam!

自動ログイン自体は以下のような流れ。
・自分のメンバー情報編集画面でチェックを行うIP全部もしくは一部を入力してもらい（最後のピリオド前は自動的に入ってる）「自動ログイン有効」を押した場合、32文字のユニークな自動ログイン専用キーが発行されクッキーに保存される。
・DBへは、そのキーと設定したIPが保存されてメンバー情報と結び付けられる。
・ログインしていない状態で本来ログインが必要な特定のアクションを行った場合、普通の認証後に（認証されたなかった場合）自動ログインの再認証が行われる。
・クッキーに自動ログインキーとユーザーIDを持っている場合（クッキーにユーザーIDは持たないようにするべき…？）そのキーが検索されてユーザー情報が取得される
・事前に設定したIPアドレスとマッチする場合は認証成功。
・IPアドレスが変わっている場合自動ログインは失敗する⇒正規のログインフォームからIDとパスワードを入力してログインする必要がある。

他に強化出来る事はないだろうか…。

次にCSRF対策

現在、半ワンタイムトークンを導入してます。
半と言うのは、実際に実行されてチケットが破棄される前であれば同じ名前のチケットを発行するアクションを行っても一定時間内(5分間)なら同じチケットIDを使いまわしているからで、これは一旦画面を移動した後、ブラウザの戻る等で戻って実行しようとするとチケットが無効になる為で、他に画面によってもっと細かくチケット名を分ける事で対策も可能だけどめんどい…。セッションも肥大化する。
同一ユーザーで同じチケット名が発行されるアクションを、複数のウィンドウで操作できないあたり今後の課題。（記事投稿画面を同じユーザー＆ブラウザで2個開いて実行すると実行してない方もチケット切れする）
チケットIDはDo系アクションで常にチェックされて、実行POSTもしくは実行GETで持つようにする。
攻撃者は、特定のURLにアクセスさせてチケットを発行させても、発行された利用可能なチケットのIDを知ってID付きのDoを正規ユーザーに実行させない限り攻撃できない。

と言う感じ。

セキュリティの問題を発見した場合は、ご連絡下さい。