徳丸さんのブログに対するコメント
(Last Updated On: 2018年8月4日)最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。 本題のブログはこちらです。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CREATE TABLE form_id (sha1 TEXT PRIMARY KEY, created TEXT NOT NULL) sha1がトークン、createdが生成日時を保持します。 シンプルな構造ですが、これだとトークンは、ユーザーやセッションを超えて、アプリケーション全体
書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記
図のように、大垣本のCSRF対策方式（以下、「大垣方式」と表記）では、トークン（同書ではフォームIDと表記）をランダムな鍵として生成（②）し、それをフォームの隠しフィールドとDBに保存します（③、④）。ユーザーがフォームをサブミット（⑤）すると、送信されてきたトークンがDB上に存在するか確認（⑥）し、あればトークンを削除（⑦）して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
