Rails にて XMLHttpRequest で POST するとセッションが切れる - 偏見プログラマの語り！
ご多分に漏れずハマったので書いておきます。(Ruby 1.9.3, Rails 3.2.2) Rails にはセッション変数 session がありますが、タイムアウトでもないのにこれが何故か空になってしまう現象が発生して、かなり悩んでました。どうも JavaScript で直接 XMLHttpRequest 発行すると発症するようです。GET ではなく POST したときのみのようです。 解決策ですが、リクエストヘッダに 'X-CSRF-Token' を追加すれば良いようです。 function post_xhr_request( url, param, on_ready ) { xhr = new XMLHttpRequest(); xhr.open( 'POST', url, true ); xhr.setRequestHeader( 'X-CSRF-Token', /* token
ログイン機能へのCSRFによるセッション固定 - 知らないけどきっとそう。
危険なのかよくわかんないですけど、はてダ初め書きます http://ido.nu/ayaya/yj.html（対策されてた！） iframe 内で http://login.yahoo.co.jp/config/login に logout=1 を POST して強制的にログアウト状態にする ログインフォームの form タグ部分をスクレイピングし、あらかじめ用意しておいた Yahoo! JAPAN ID とパスワードを埋め込む その HTML を iframe にロードし、submit() で POST させることにより、用意しておいたアカウントでログインさせる メールで「住所情報を更新しないとアカウントが消えます」とか書いて誘導したら、どのくらい釣れるかなあ あーあと、個人情報の入力だけじゃなくて、OAuth の認可とか権限を与える操作もまずい ページは SSL になっていて、アドレス
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
CWE-352
Compound Element ID:352(Compound Element Variant: Composite) Status: Draft クロスサイトリクエストフォージェリ 解説 解説要約 本脆弱性が存在する Web アプリケーションは、フォーマットに沿った、妥当で一貫性のあるリクエストが、送信したユーザの意図通りに渡されたものかを十分に検証しない、あるいは検証が不可能です。 詳細な解説 Web サーバがリクエストを検証せずに受け取るよう設計されている場合、攻撃者がクライアントを騙し、意図しないリクエストを Web サーバに送信させる可能性があります。その場合、Web サーバはそのリクエストを正規のものとして取り扱います。 この攻撃はURL、画像の読み込み、XMLHttpRequest 等を介して行われ、データの漏えいや意図しないコードの実行を招く可能性があります。
セキュリティ講習(7)Same Origin Policy
「Webセキュリティ (7)Same Origin Policy」というタイトルで社内勉強会を開催しました。今まで1回も公開してないんですが、実はセキュリティの社内講習会は7回目です。近いうちに残りの6回分も公開します。 まとめ Same Origin Policy 同一ホストだけ信用するポリシー 同一ホストのみ別URLのDOM操作が可能 崩されると間接攻撃されるのと同等の脅威 「信用できないユーザが同一バーチャルサーバにJS/HTMLを設置できる場合、セキュリティ的にアウトだよ」ということを再確認しました。 ムービー 発表資料 スライド(PDF) 内容の補足など 「クロスサイト通信とセキュリティ」という章を時間の都合で削りました。このあたりもいずれ話したいところです。 参考資料 同一生成元ポリシー - MDC Mozillaの技術紹介ページ。 document.domainの書き換えとi
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
pixiv開発者ブログ:［不具合報告］意図しない作品へのコメントについて
2010年02月15日お知らせ pixiv事務局です。 このたび、一部ユーザー様の作品へのコメントが改ざんされたとの報告があり、弊社にて調査をいたしましたところ、「作品のコメント欄」の脆弱性を利用した不正が行われていた事実が判明いたしました。 本件の詳しい状況につきまして、下記の通りです。 ・経緯 2010年2月5日より2月14日までの間、一部ユーザー様の作品において、ユーザー様の意図によらないコメントが書き込まれた旨のお問い合わせを頂きました。 お問い合わせをいただいた後、該当する全てのサーバのログ・関連データベースを調査しましたところ、問題となったコメントの書き込みの前に、あるURLへアクセスし、外部サイトを経由をした後にコメントを投稿した形跡を発見しました。 また、本不具合を利用したアクセスを調査しましたところ、影響があったのは作品へのコメントの書き込みのみで、他の機能へ
「ヘタクソ」pixivに意図せず中傷コメント CSRF脆弱性を悪用
イラストSNS「pixiv」の一部の作品に対し、「ツマンネ」「ヘタクソ」「気持ちわる」といった中傷コメントが意図せずに投稿されてしまう問題が起きた。運営会社が調べたところ、何者かがユーザーに脆弱性を悪用した外部URLをクリックさせ、意図しないコメントを投稿させていたことが分かり、既に脆弱性は修正した。 ピクシブの開発者ブログによると、問題は2月5日～14日に発生。イラストのキャプション欄などに貼られていたあるURLをクリックすると、外部サイトを経由し、中傷コメントが投稿されるようになっていた。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を悪用していた。脆弱性は14日に修正した。アカウントが乗っ取られたわけではなく、個人情報の漏えいや改ざんはないとしている。ウイルス感染の被害もないという。 pixiv
へぼへぼCTO日記 - PlackにおけるCSRFとDNS-Rebinding対策
最近のwebセキュリティ界隈ではCSRFやDNS-Rebindingが話題ですが、Plackでアプリケーションサーバを立ち上げる際にこれらの対策をどのように行うかについてまとめてみました。 まず、CSRF対策ですが、拙作のPlack::Middleware::RefererCheckを使うことにより、RefererのチェックによるCSRF対策が行えます。CSRF対策としては、onetime token方式も存在しますが、個人的にはRefererチェックが導入が楽で好きではあります。Refererを送信しないクライアントを対象にしたサービスを運営される方は別途onetime token方式の対策をおこなってください。 Plack::Middleware::RefererCheckの使い方はこのようになります。(SYNOPSYSからの抜粋) use Plack::Builder; builde
soheiのブックマーク / 2009年12月19日 - はてなブックマーク
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
はまちや２ on Twitter: "「ほまちや」の名前でぼくの何かを模倣したものが出回ってるみたい。 url踏むと何かを勝手に追記するのではなくて、元々のプロフとかを消去して書き換え感染していくたぐい。怖いね。通報しとこっと"
「ほまちや」の名前でぼくの何かを模倣したものが出回ってるみたい。 url踏むと何かを勝手に追記するのではなくて、元々のプロフとかを消去して書き換え感染していくたぐい。怖いね。通報しとこっと
ミニミニブログにCSRF脆弱性 - ockeghem's blog
前回に引き続き、はじめてのPHPプログラミング 基本編5.3対応のゆるいところ第三段は、本書に紹介されているミニミニブログにクロスサイト・リクエストフォージェリ(CSRF)脆弱性があるというものだ。 このミニミニブログは、BASIC認証を利用していて、twitterやwassrなどのように一行コメントが書き込めるというものだ。BASIC認証、投稿機能があればCSRF脆弱性の対策が必要だが、本書にはCSRFに対する解説は特にないので、調べるまでもなくCSRF脆弱性があるのだろうと思っていた。 しかし、人様の書籍に確認もしないで脆弱性指摘をするのも失礼なので、以下のように簡単な検証コードを書いて試してみた。 <html><body> <form action="http://localhost/hajimete_php5/miniblog/index.php" method="post"> <
セキュアなPHPアプリケーションを作成するための7つの習慣 | 水無月ばけらのえび日記
公開: 2024年3月10日18時15分頃 徳丸さんツッコミシリーズ、「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い (d.hatena.ne.jp)。「セキュアな PHP アプリケーションを作成するための 7 つの習慣 (www.ibm.com)」のサンプルコードがあんまりだというお話ですね。 個人的には、CSRFのサンプルコードが印象的でした。前置きとしてこう書かれていて……。 CSRF から保護するためには、フォームの投稿を検証するための習慣で使用する、ワンタイム・トークンによる手法を使います。また、$_REQUEST ではなく、明示的な $_POST 変数を使う必要があります。 以上、セキュアな PHP アプリケーションを作成するための 7 つの習慣 より まあ、この記述の前半はそんなに間違っていないのですが、後半は微妙なところですね。何
サイボウズのグループウェア製品に3件の脆弱性
ガルーンやOfficeのグループウェア製品にクロスサイトリクエストフォージェリなど3件の脆弱性が発見された。 情報処理推進機構（IPA）セキュリティセンターとJPCERTコーディネーションセンターは6月27日、サイボウズのグループウェア製品「サイボウズ Office」などに3件の脆弱性が発見されたとして、JVN(Japan Vulnerability Notes)に情報を公開した。 発見された脆弱性は、クロスサイトリクエストフォージェリ（CSRF）とクロスサイトスクリプティング（XSS）、セッション固定の合計3件。対象製品は、CSRFがサイボウズ Office 6およびサイボウズ デヂエ 6.0（1.0）より前のバージョン、サイボウズ ガルーン 2.0.0～2.1.3。XSSとセッション固定がサイボウズ ガルーン 2.0.0～2.1.3となっている。 CSRFの脆弱性では、ユーザーが該当製
高木浩光＠自宅の日記 - ハマチをちゃんとテリヤキにするのは難しい, CSRF脆弱性を突く攻撃行為を現行法で処罰できるか
■ CSRF脆弱性を突く攻撃行為を現行法で処罰できるか CSRF脆弱性が攻撃されることは、それがもたらす被害の内容によっては、不正アクセス禁止法が守ろうとしているものと同等のものが侵害される場合もある。たとえば、本人でなければ見ることのできないはずの情報が、CSRF脆弱性を突く罠を仕掛けた者に送信されるといった攻撃は、不正アクセス行為の典型的な侵害事例と同様の被害をもたらす。また、同法の目的である「アクセス制御機能により実現される電気通信に関する秩序の維持」（第1条）が損なわれるという点も共通する。 しかしながら、CSRF脆弱性を突く攻撃行為は、結果が同じてあっても手段が異なるために、不正アクセス禁止法による処罰は難しいのではないかと以前から思っていた。これについては、2005年7月3日の日記「クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか」にも書いた。
諸君 私は脆弱性が好きだ
諸君 私は脆弱性が好きだ 諸君 私は脆弱性が大好きだ PHPが好きだ XSSが好きだ SQLインジェクションが好きだ CSRFが好きだ UTF-7が好きだ expressionが好きだ シェアウェアで Webで Googleで スペシャルねこまんまで LiveHTTPで Filemonで Regmonで OllyDbgで Perlで この地上に存在するありとあらゆる脆弱性が大好きだ セキュリティに関して口うるさく言っているサイトの脆弱性をいとも簡単に見つけるのが好きだ 大企業のサイトがGoogleによって脆弱性を発見された時など心が踊る Googleがあっけなく脆弱性を見つけてしまうのが好きだ Perlを馬鹿にしていた奴のアカウントを乗っ取った時など胸がすくような気持ちだった 粘り強い同業者がMS Officeのシリアル認証と格闘している様が好きだ PHP覚えたての野郎共が続々と脆弱性を作
Amazonのすごいアクセス解析サービス - ぼくはまちちゃん！
こんにちは！ Amazonほしい物リスト、すごい話題になってますね！ なんでも、メールアドレスで検索すればAmazonに登録してある本名がでてくる (ケースもある) とか…。 で、さっそくぼくも試してみたよ！ ほしい物リストサーチ！ これって、いま話題になっているのは、誰かのメールアドレスを手がかりにして ウィッシュリストや本名、下手すると住所まで知られてしまうってところだよね。 それだけでも面白いんだけど、 あまり注目されていない機能として、こんなものがあったよ。 友だちにほしい物リストについて知らせる これ。 自分のほしい物リストを誰かにメール送信できちゃう機能らしいね！ じゃあ試しにメール送信時のリクエストを確認してみると… http://www.amazon.co.jp/gp/registry/send-nudge.html?ie=UTF8&type=wishlist&__mk_j
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JVNDB-2012-000029 - JVN iPedia - 脆弱性対策情報データベース
ワンタイムトークン｜脆弱性診断.jp