んっと。Cross Site Request Forgeries ってのがあるです。
「ど〜やってガードするか」の理論構築をしてみた………のはいいのですが、どうももう一つ自信に欠ける。
という訳で。Blogに書いたらあるいはどなたかが突っ込みなどしてくださるのではないか、という、大変にWeb2.0的(他力本願とかいうな)な発想で書き込みをしてみます(笑
前提：ログイン状態が保持できること
セッションID(以降 sid)を使っててけとうに処理し、「１ユーザであることが認識できる」事を前提とします。
また、「sidをド〜にかすることによるクラック」は「sidのロジック側でど〜にかしてもらう」ことを期待したいので、言及しません。
もう一つ。いわゆるMVC系の「入り口は一本で、URLパラメタ若しくはURLそのもの(をmod_rewriteとか)で必要なModelを振り分ける」事を前提としています。そいつを以降「画面ID」とか呼称します。
…って思ったけど。「自プログラムの名前」が取れるので、応用は容易いかもしれません。
副作用：一方通行系ロジックになる
画面に対して「この方向にしか進んでくれるな」的な縛りを入れます。
っていうかぢつは「その縛りを考えてるときに思いついた」ロジックなので。
どっちかってぇと「CSRF対策のほうが副作用」なのかもしれません。
手法：チケット発行
ワンタイムチケットテーブルには、以下の情報が入っています
- ワンタイムチケットそのもの：これがなきゃ始まりませぬ
- sid：ユーザを一意に識別したくてねぇ
- お時間：あんまり長い時間は認めたくないので
- 画面ID：Listになりうるので、これは別テーブルのほうがいいかも。でなきゃ適当に区切って
2006/11/22 追記
突っ込まれて書き忘れたの思い出した(苦笑
ワンタイムチケットは「必ず」Cookieに入れてください。これによって「リロードされてもOK」になるです。
hiddenに入れちゃうとリロードされたときにどもできなくなります。
手法：処理全般
概ねこーゆー処理が入ります。
・一方通行(CSRF制御)開始Page
とにかくいいからチケット発行して終わり。「次に遷移しうる画面」の画面IDをセット
・途中Page
まずチケットのチェック。「同一のワンタイムチケット＆sid」で、且つ「DBの画面IDのListの中に自分の画面IDがあること」。ついでにお時間もチェックよろ。
OK/NGのこだわりなく、一度チェックしたワンタイムチケットはとにかく破棄。
問題があったらNGですっとばしてfin。
OKなら、チケット発行。画面IDの項目には自分自身＋「次に遷移しうる画面」の画面IDをセット。
やれやれ。ようやく本処理だよ。
途中Pageで自分を入れるのは「ついリロードしちゃったよヲイ」対策です。
多分。これでなお抜かれるのは「物凄くリアルタイムに抜いた時」のみだと思うのと、それにおいてなお、正式なユーザが「NG画面で危険を認識して大騒ぎしてくれる」ので、なんとかなるかなぁとか思ってるのですが。
手順的に「へんだよヲイ」とかってのがありましたら是非メールでもコメントでも頂戴したく。
