CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
攻撃者がセッション ID を入手可能な状態で CSRF 攻撃を仕掛ける可能性について検討した - co3k.org
仕事で「フレームワークで使ってる CSRF 対策用トークンがセッション ID を基にいろいろ組み合わせた文字列のハッシュなんだけれども、なんでセッション ID 直接使わないんだよう」的な話が出たので、なんでだろうなーと考えつつ理由について検討してみたので以下に一部晒してみます（社内向けに書いたものなのでいろいろ雑だったりするのはごめんね）: 推測ですが、セッション ID が GET パラメータとかに含まれたりする可能性を避けたかったんじゃないかなあとか思います（フォームは GET でも使われうることを想定している）。 GET パラメータにセッション ID のような種類の情報は含めるべきではありません。 あと、セッション ID が盗まれた場合でも CSRF 攻撃を受けないようにするという意図もありそうな気がします。攻撃者がセッション ID を知っている状況で CSRF 攻撃を選択する状況につ
「CSRF」と「Session Fixation」の諸問題について
1 「CSRF」と「Session Fixation」 の諸問題について 独立行政法人産業技術総合研究所 情報セキュリティ研究センター 高木 浩光 http://staff.aist.go.jp/takagi.hiromitsu/ 情報処理推進機構 ウェブアプリケーション 開発者向けセキュリティ実装講座 2006年2月28日, 4月4日 後日配布資料 2 目次 • 前提知識の確認 – Webアプリにおけるセッション追跡と認証の実装手段 – セッションハイジャック攻撃の原理と脅威 • CSRF (Cross-Site Request Forgeries) 別名: Session Riding – 歴史的経緯、原因、脅威、技術的対策、適法な存在推定手段 • Session Fixation – 歴史的経緯、原因、脅威、技術的対策、適法な存在推定手段 3 セッション追跡と認証の実装手段 • セッ
Web セキュリティに関するインターンで伝えようとしたこと - co3k.org
これは VOYAGE GROUP エンジニアブログ：Advent Calendar 2014 の 17 日目のエントリです。 VOYAGE GROUP では もの創り実践プログラム Treasure というエンジニア向けインターンシップを開催しています [1] [2] 。 Treasure 全体の様子は既に VOYAGE GROUP エンジニアブログにて 前編 と 後編 に分けて紹介されていますが、このエントリでは、前半パートにおいて僕が担当した Web セキュリティに関する講義についてお話ししていきます [3] 。 講義は休憩や実際に手を動かしてもらいつつで 3 時間半という長丁場でしたが、なぜか随所で笑いが巻き起こる状態で非常に評判がよく、同じ内容を 独立した 1 day インターンシップとして京都でも開催 させていただけました [4] 。これもひとえに必死に内容に食らいついてくれたイ
Endpoint Protection - Symantec Enterprise
過去数カ月、ソーシャルネットワークサイトへと誘導しようとするさまざまなスパム攻撃が確認されています。これらの攻撃のほとんどは、何らかのソーシャルエンジニアリング手法の特徴を備えていますが、ときとして、画期的なソーシャルエンジニアリング手法も登場しています。ここでは、そうした手法のなかでも、Facebook で特に重要な CSRF 対策トークンを盗み出そうとしてユーザーを欺く手口を紹介します。 クロスサイトリクエストフォージェリ攻撃 クロスサイトリクエストフォージェリ（CSRF）とは、ある Web サイトで認証済みのセッションを再利用して、ユーザーに気づかれないまま、または同意を得ずにその Web サイトで悪質な処理を実行する攻撃です。たとえば、ユーザーが自分のオンラインバンキングのサイトにログインしているとします。この Web サイトに CSRF の脆弱性があると、別の悪質な Web サイ
IPAから「クリックジャッキング」に関するレポート出ました
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。 このレポートから、クリックジャッキングのイメージを示す図4を引用します。 サイトAが攻撃対象のサイト、悪意のあるページは罠にな
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった