ふつうのリロード対策

ネタ元： 【PHP TIPS】58. すごいリロード対策

これはいろいろ気になったので、思ったことを書いておく。

ふつうのリロード対策

一般的な登録フォームの画面遷移は、

入力画面→入力確認画面→完了画面

であるかもしれないけど処理の流れとしては、

入力画面表示処理→入力確認画面表示処理→登録(メール送信)処理→完了画面表示処理

になる。

処理を分けることにより、完了画面でリロードされても、二度も登録処理が行われることはない。

個人的には、完了画面で登録(メール送信)処理を行うのは、あまり好きではない。

登録(メール送信)処理と完了画面表示処理を同一処理上で行おうとすると、面倒なリロード対策を行わなくてはいけない。

それで件のページの内容に行き着く。

すごいリロード対策

件のページの内容が『すごい』というのはCSRF(クロスサイトリクエストフォージェリ)対策を同時に行っている点でしょう。

CSRFは、通常のフローを通らずに登録処理だけを行おうとする攻撃である。コメントスパムなんかがよい例。

CSRF対策としては、『リファラーチェック』と『セッションを使用したワンタイムチケット』がメジャーな対策ですが、どちらも一長一短。

リファラーチェックは文字通り、前のページをチェックして正しくない場合は処理を行わない対策。問題点としてはデバイスがリファラをはかない場合もCSRFとみなされてしまう。

セッションを使用したワンタイムチケットは、確認画面で発行したチケットを登録処理でチェックする対策。問題点としてはセッションに対応してないデバイスの場合、CSRFとみなされてしまう。
また、携帯などセッションの処理がややこしいデバイスに対応する場合は実装が非常にめんどくさい。

CSRF対策はベストと思われる対策が存在しないので、個人的にはよほどスパムが多い場合か、神経質に処理しないといけない場合でないと実装しないです。(スパム対策の場合は英字フィルタリングなどで対応するのがほとんどですが)

リロード処理とCSRF対策を同時に実装することにより、そこらへんのさじ加減ができなくなるので微妙ですね。

後、ネタ元のスクリプトだと複数の確認画面が開かれた場合、セッションが上書きされて正常に登録できない場合が発生する。(しかも、完了画面がちゃんと表示されるんですよ)

p4lifeのメモさんが対応したコードを紹介しているので、こちらを参考にされたほうがよいです。

関連エントリー

WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門

スポンサードリンク

«Re:Creator's Kansai　Photos | メイン | PHP教育無料体験キャンペーン»