今年9月，Gmailにクロスサイト・リクエスト・フォージェリ（CSRF）のぜい弱性が見付かった。ユーザーはメールを盗み見される危険にさらされていた。また，10月にはバッファローの無線LAN製品「AirStation」に組み込まれている設定ツール（Webアプリケーション）に存在するCSRFのぜい弱性が発見された。第三者にAirStationの設定を勝手に書き換えられる可能性があった。 これらのぜい弱性は， ユーザーがWebアプリケーションにログインした状態で，攻撃者が用意した悪意のあるリンクを誤ってクリックすると，ユーザーが予期しない処理を実行されてしまうというもの。Gmailなら例えば勝手にフィルタ・プログラムを作成して任意のアドレスにメールを転送するなどの仕組みを実現できる。 グーグルは既にこのぜい弱性を修正済みだが，万が一，利用者のフィルタ・リストに攻撃者が作成したフィルタが存在してい
Enterprise Strategy Group: Go-to-market Expertise to Help You Win
クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF（シーサーフ (sea-surf) と読まれる事もある[2][3]）、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。 なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の
本日20時頃、特定のタグを貼り付けたページを閲覧するだけで、はてなにご登録いただいているアフィリエイトIDが書き換わってしまう脆弱性が存在する事が判明しました。 この脆弱性について、先ほど修正を行いました。現在、この脆弱性は修正されております。 脆弱性の内容 特定の引数を指定した画像タグを使用する事で、ページの閲覧者がアフィリエイトページで設定を変更した操作と同等の操作が可能となっておりました。 今後の対応について 現在被害状況を調査中ですが、アフィリエイトIDの書き換えが行われた方が現在200名程度確認されています。 今後さらに詳細な調査を行い、被害者の方には随時個別に今回の状況説明と、アフィリエイトID再設定のご連絡を行わせていただきます。 また、同様の脆弱性が存在しないか、改めて他のページについても確認を行います。 このたびははてなシステムの不備により、ユーザーの皆様にご迷惑をおかけ
CSRF対策に「ワンタイムトークン」方式を推奨しない理由 @ 高木浩光＠自宅の日記 ものすごく遅くなってしまったが、高木氏の反論を読ませて頂いた。 ワンタイムトークン方式の欠陥 (拙作の)「ワンタイムトークン方式」では複数の画面遷移を実装できない、という点についてはまさにその通りで反論の余地はない。僕が提唱した方法では、同一セッションで2つ以上の画面遷移を平行して行った場合、先にワンタイムトークンを発行した方の処 理がエラーを起こしてしまう。 「ワンタイムトークンを変数で切り分ける」方式(僕が提唱したものではないが)についても、高木氏の言う通りで現実的ではないと思う。全く同じ画面の平行編集についても、同じ人へ複数のメッセージ(メール)を送る場合など必要と思われる場面はいくつか想定できる。 で、hiddenにSessionIDを入れるのは問題ないの？ 高木氏やおおいわ氏の主張は
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、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）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
高木浩光＠自宅の日記 お忙しいようですが、以前僕が触れたCSRF対策に関係するので言及を許してください。最近立て続けにツッコミを入れているので心苦しいのですが……。 以前高木氏がCSRF対策について「セッションIDをhiddenに入れればよい」と書かれました。その時僕は「キャッシュに残ると危険だ」という理由「など」でその対策は適切ではないと主張した(CSRF対策法と効果参照)が、僕と同様の主張に対して以下のような反駁があった。 cacheが残るのは脆弱性か まず、cacheは禁止するのが当然であり、cacheを禁止してもcacheに残る場合というのは、Webアプリケーションの責任ではない。残るような製品の脆弱性である。 「cacheの禁止」というのは「Pragma: no-cacheやCache-Control: no-cache」などのサーバーからUAへの指示のことだと解釈した
■ [Security] hidden field に session ID を入れる CSRF 対策方法に対する反論に対する反論 ああ、禅問答のようなタイトル。 前から、「おさかなラボ」なるページで 高木浩光氏の推奨するCSRF対策は安全でない、との主張が 展開されていたので注目していたのだが、最近↑のページの再反論がでて、やっと僕の中では結論がでた感じ。 で、結論は、「やっぱり彼の主張は反論になってない」でよさそう。 正直、再反論の主張を見て、思ったような内容じゃなくてちょっとがっかり。 彼はずっと、「hidden フィールドはキャッシュから漏洩する」と主張していたので、 きちんと対策していてもそういうことが起こる状況想定を何か持っているのかと期待していたのだが、 再反論での主張は「たとえ Pragma: no-cache していても、cache のディスクに残る可能性はあるから駄目だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
