高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
CSRF対策, Login GeneratorのSession Fixation Attack対策, クッキーのパス, セッションファイルの作成場所 - Journal InTime(2005-07-15)
_ CSRF対策 0.13.0にもCSRF対策のコードはとくにないようだ。 MLの議論を追ってなかったのだが、結局アプリケーション側で対策する べしということだろうか。 まず、ApplicationControllerとApplicationHelperに以下のような記述をしておく。 app/controller/application.rb: class ApplicationController < ActionController::Base private def validate_session if @params[:session_id_validation] == @session.session_id return true else render(:text => SESSION_VALIDATION_FAILED_HTML, :status => "403 Forbi
CSRFの対策のテスト - zorioの日記
Ruby On Railsでは、フレームワークでCSRFに対する対策は取られておらず、アプリケーション側の責任になっている。 具体的にどうしたら良いのかは、http://shugo.net/jit/20050715.htmlを参照。 では、ajaxを使ってる場合はどうするのかを調べたのが、昨日のid:zorio:20060317:1142619114。 Functional Testでsession_idを操作する必要が出てきたのだが、ちょっと大変だった。 Functional TestでのSession リクエストを送る際、すなわち、テストの実行時点で既にセットされているセッション変数は、リクエストの引数にハッシュで渡すことになっている。 get :action, :parameters=nil, :session=nil という感じ。 リクエストの実行後は、sessionという名前でセ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://shotawatanabe.com/2006/04/csrf.html
メッセージ
CSRFの対策 - zorioの日記
