VAddyとCSRFトークン VAddyは脆弱性診断を実行する際に、CSRFトークンを最新のものに更新しながら動作します。そのため「どのパラメータがCSRFトークンか？」を判断するロジックが存在しています。最近あるフレームワーク（後述）について「CSRFトークンを正しく認識できない」というバグを修正したのですが、良い機会なのでメジャーなフレームワークやCMSを中心にCSRFトークンの実装をざっと追ってみました。一覧にしても面白くないので、仮想インタビュー形式にまとめてあります。GitHub上で軽く追ったものが多いので、最新のバージョンでなかったり、解釈が間違っている箇所があるかもしれません。 それでは、どうぞ。 Ruby on Rails 金床(以下、金)「こんにちは。ようこそ。」 RoR「こんにちは」 金「相変わらずシェア高いようですね。」 RoR「はい、おかげさまで。この間はルマン24
2015年12月に私が発見した VALUE-DOMAIN での CSRF 脆弱性について、その脆弱性の報告と修正までの経緯を記しておきます。 きっかけ アカウント削除ページの作り アカウント削除ページの問題点 VALUE-DOMAIN への報告 CSRF 攻撃によるアカウント乗っ取りの問題 IPA への届出 余談：IPA への届出の仕方について IPA へ届出した後の状況 VALUE-DOMAIN ユーザの方へ きっかけ 数年前に VALUE-DOMAIN を利用していましたが最近は使っていないのでアカウントを削除しようとしたところ、アカウント削除操作を行うページの作りが「不自然である」ことに気付きました。更に調べたところ CSRF 攻撃によってアカウント乗っ取りが可能な状況であることが分かりました。 アカウント乗っ取りが可能な CSRF 脆弱性は2015年12月22日にIPAに報告し、2
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
HTTP ガイド HTTP の概要 典型的な HTTP セッション HTTP メッセージ MIME タイプ（IANA メディア種別） HTTP の圧縮 HTTP キャッシュ HTTP 認証 HTTP Cookie の使用 HTTP のリダイレクト HTTP 条件付きリクエスト HTTP 範囲リクエスト コンテンツネゴシエーション HTTP/1.x のコネクション管理 HTTP の進化 プロトコルのアップグレードの仕組み プロキシサーバーとトンネリング HTTP クライアントヒント HTTP セキュリティ サイトの安全化 HTTP Observatory Permissions Policy コンテンツセキュリティポリシー (CSP) オリジン間リソース共有 (CORS) Cross-Origin Resource Policy (CORP) Strict-Transport-Securit
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
TwitterのOAuth脆弱性 Presentation Transcript TwitterのOAuth脆弱性 2013-03-01 Xtone Ltd. ピザ会 Aki / @nekoruri なにがおきたの？( ^o^) なんか友達からURL送られてきたお なにがおきたの？( ˘⊖˘) 。o(ID/Pass入力しなきゃ安全だよな……) なにがおきたの？|URL| ┗(☋｀ )┓三 なにがおきたの？( ◠‿◠ )☛ アクセストークンは頂いた、抵抗は無意味だ なにがおきたの？▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ なにがおきたの？( ^o^)なんか友達からURL送られてきたお( ˘⊖˘) 。O(ID/Pass入力しなきゃ安全だよな……)|URL| ┗(☋｀ )┓三( ◠‿◠ )☛アクセストークンは頂いた、抵抗は無意味だ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああ
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
■ CSRF脆弱性を突く攻撃行為を現行法で処罰できるか CSRF脆弱性が攻撃されることは、それがもたらす被害の内容によっては、不正アクセス禁止法が守ろうとしているものと同等のものが侵害される場合もある。たとえば、本人でなければ見ることのできないはずの情報が、CSRF脆弱性を突く罠を仕掛けた者に送信されるといった攻撃は、不正アクセス行為の典型的な侵害事例と同様の被害をもたらす。また、同法の目的である「アクセス制御機能により実現される電気通信に関する秩序の維持」（第1条）が損なわれるという点も共通する。 しかしながら、CSRF脆弱性を突く攻撃行為は、結果が同じてあっても手段が異なるために、不正アクセス禁止法による処罰は難しいのではないかと以前から思っていた。これについては、2005年7月3日の日記「クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか」にも書いた。
こんにちはこんにちは！！ 今日はCSRF脆弱性のちょっとした話です！ このCSRFってなにかっていうと、 サーバーへのリクエストを『誰かに勝手に送らせる』っていうセキュリティがらみの攻撃手法のひとつ。 わかりやすい例だと、 HTMLの画像タグを以下のようにしたページを誰かに教える。 <img src="何々SNSの足跡.php" width="1" height="1"> そうすると、そのページを「見た人」が何々SNSの足跡.phpにアクセスしたことになる。 ※詳しくはこちらのマンガで → ［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！ ： 第2回 しーさーふって何ですか？ CSRFってこんな風に、 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対
(つかいかた) 1. 適当にrequireする。 require 'easy_csrf.php'; 2. 適当にsession_start()しておく。 session_start(); 3. (HTML) submitの手前に次の一文をいれる <input type="hidden" name="<?= EasyCSRF::KEY_NAME ?>" value="<?= EasyCSRF::generate() ?>" /> 4. データを受け取る箇所で次のようにする if (! EasyCSRF::check($_POST[EasyCSRF::KEY_NAME])) { echo '送信されたデータが、なんかおかしいです'; die(); } コード (こぴぺして使おう！) <?php // easy_csrf.php // by Hamachiya2 // 2012.02.15 cl
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
こんにちは！ 「フォームを勝手にサブミットしてしまう」 その認識でだいたいあってます！たぶん！ そのmixiの例だと、 入力画面 → (送信1) → 確認画面 → (送信2) → 完了 ってなるわけですが、 いくら確認画面が間にあったところで、 (送信2)の部分を「勝手にサブミット」しちゃえばいいわけです。 ※ただし今のmixiや、ちゃんとしたwebサービスは送信時にトークンをつけるとかCSRF対策してるのでできません 実際の攻撃の例としては、mixiやtwitterなどの多くの人が繋がっている投稿型サイトで、 「こんにちはこんにちは！！ このリンク先すごいよ！ http://～」 のような書き込みをしておき、 そのリンク先でformやJavaScript等で「自動的に勝手にサブミット」してしまいます。 画面には何も表示されなくてもかまいません。 そしてさらに勝手に書き込む内容を 「こんに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
