Rails 2.0でCSRF対策 - cys b
Rails 2.0ではCSRF（cross site request forgery, クロスサイトリクエストフォージェリ）対策が標準で入っているって事でActionController::RequestForgeryProtection::ClassMethodsのRdocを読みながら試した。まず、以下の様なコントローラ（top_controller.rbとした）を作る。 Railsアプリのルートで ./script/generate controller top index （だっけ？） top_controller.rbの中身は以下の通り。 class TopController < ApplicationController protect_from_forgery :secret => 'my-little-pony', :only => :index def index end
hata's LABlog: CSRF対策 with JavaScript
JavaScript を使った CSRF 対策の方法として、以前 Kazuho@Cybozu Labs で紹介されました。 CSRF 対策 w. JavaScript CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。 ここでさらに一歩進めて、既存の FORM 要素に onsubmit 属性、および hiddenフィールドを直接追加せずに、JavaScript ファイルを１つインクルードすることにより、既存アプリケーションの書き換えをさらに少なくする方法を紹介したいと思います。 以下の JavaScript ファイルをHTMLの最後でインクルードする方法です。 fight_csrf.js sessid_name = ""; scripts = docume
tDiary.org
Web日記支援システムtDiaryにおいて、クロスサイト・リクエスト・フォージェリ(CSRF)の問題が発見されました。 対象 この問題が存在するtDiaryは以下のバージョンです。 tDiary 2.0.1およびそれ以前 tDiary 2.1.1 想定される影響 悪意ある第三者が特殊なURLや外部ウェブページを生成することで、日記の改竄や削除、設定の変更などの操作を、ログイン中のユーザに不正に行わせることができる可能性があります。さらに、tDiaryが動作するWebサーバ上で任意のスクリプトやコマンドがtDiaryの実行権限にて実行される可能性があります。 対策 tDiary開発プロジェクトでは、対策を実施した以下のバージョンを公開しています。 tDiary 2.0.2 (安定版) tDiary 2.1.2 (開発版) 対策は以下の通り、日記の更新および設定の変更時に新たにいくつかのガード
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
おさかなラボ - クロスサイトリクエストフォージェリ対策
過去の議論はこちら 一般的に言われている対策と実際の有効性についてはこちら 一般にCSRFはセッションの利用に伴う脆弱性なのだから、予測不能な文字列を生成してhiddenとセッション内(PHPセッションの場合$_SESSION内)に入れておき、完了画面でこの2つを照会する方法が簡便で堅牢だと考えられる。(要はセッションを使ったワンタイムトークン方式)。 この対策だけでも充分だが、hiddenを横取りされた場合に発生する脆弱性に備え、Cookieでも比較を行う。 実際のコード // 確認画面 session_start(); (認証など略) $uniq_id = md5(uniqid(rand(),1)); // 推測不可能な文字列を生成 $_SESSION['uniq_id'] = $uniq_id; // セッションに保存 setcookie('uniq_id',
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://del.icio.us/spiegel/CSRF