SameSite攻撃者がCodeIgniter4とShieldでのCSRF保護を回避できる脆弱性の解説 — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
CodeIgniter4とCodeIgniter Shieldでの組み合わせで、CSRF保護を回避できる脆弱性に関するセキュリティ勧告が2022/08/08に公表されました。今日は、この脆弱性について解説しておきます。 SameSite Attackers may Bypass the CSRF Protection · Advisory · codeigniter4/shield なお、この攻撃方法はCodeIgniterに限定されるものではありません。 修正済みのバージョン CodeIgniter 4.2.3 CodeIgniter Shield 1.0.0-beta.2 前提条件 この脆弱性を攻撃するには、攻撃者が攻撃対象のサイトと同じドメインのサブドメインサイトを支配下に置いている必要があります。 簡単に言えば、サブドメインサイトのページを書き換えられるということです。これはそのサ
2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか
サマリ2020年2月にGoogle ChromeはCookieのデフォルトの挙動をsamesite=laxに変更しましたが、2022年1月11日にFirefoxも同様の仕様が導入されました。この変更はブラウザ側でCSRF脆弱性を緩和するためのもので、特定の条件下では、ウェブサイト側でCSRF対策をしていなくてもCSRF攻撃を受けなくなります。この記事では、デフォルトsamesite=laxについての基礎的な説明に加え、最近のブラウザの挙動の違いについて説明します。 （2022年1月29日追記） 本日確認したところ、Firefoxにおけるデフォルトsamesite=laxはキャンセルされ、従来の挙動に戻ったようです（Firefox 96.0.3にて確認）。デフォルトsamesite=lax自体は先行してGoogle Chromeにて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
解答：CSRFの防止策に関するチートシートにツッコミを入れる
この記事は、先日の記事「問題：CSRFの防止策に関するチートシートにツッコミを入れる」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 設問: チートシート旧版の翻訳であるJPCERT/CC訳（以下の引用部分）を元に以下の設問に答えよ。 引用（再掲） Cookie の二重送信 Cookie の二重送信は、Cookie およびリクエストパラメーターの双方でランダムな値を送信し、サーバー側で Cookie の値とリクエストの値が等しいかどうか検証する手法です。 ユーザーがサイトにログイン するとき、サイトは暗号強度の高い疑似ランダム値を生成し、その値を Cookie としてユーザーのマシンに、セッション ID とは別に送ります 。どんな形であれ、サイトはこの値を保存しておく必
SPAセキュリティ入門～PHP Conference Japan 2021
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
PHPでCSRF対策を自動的に行う方法
Last Updated on: 2018年8月13日PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを１つインクルードする以外、ほとんど何も行う必要がありません。 CSRF Protection for PHPの機能 自動的にHTMLフォームやリンクにCSRFトークンを追加 CSRFトークンの有効期限を設定可能 まだまだ多くのアプリケーションが固定かつ有効期限を設定しないのCSRFトークンを使っています。この状態では一旦CSRFトークンを盗まれると、攻撃者にいつまででも攻撃される可能性があります。 このスクリプトの場合、有効期限付きのCSRFトークンをWebページに自動追加して防御します。 後で記載するようにPHP 7.1でoutput_rewrite_var()のバグを完全に直しました。なのでPHP 7.1以降の利用がお勧めで
より高度なCSRF対策 – URL/URI個別にバリデーションする方法
Last Updated on: 2018年8月13日ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。 論理的な背景 まず前提条件となる知識を整理し、なぜこのエントリのようなハッシュ関数の使い方をしているのか紹介します。 大別するとハッシュ関数には二種類あります。ハッシュ関数の種別を正しく区別することが重要です。 暗号学的なハッシュ関数 – SHA2など 暗号学的でないハッシュ関数 – CRCなど 暗号学的なハッシュ関数には次の特徴があります。 同一のハッシュ値であるのに、そっくりだが実は異なるというようなメッセージの作成が不可能であること ハッシュ値から、そのようなハッシュ値となるメッセージを得ることが(事実上)不可能であること（
セッションIDをCSRFトークンに使うべきでない理由
malaさんも2年程前に書かれているのですが、未だに国内のCSRF対策の解説で「セッションIDをCSRFトークンとして使う」というアイデアが披露されていて辟易します。 喩え話は好きでないですが、「複数のサイトで同じパスワードを使っていたら一箇所から漏洩し、パスワードリスト攻撃を受けた」というのを彷彿します。セッションIDとCSRFトークンは単純に別の値にした方がいいです。 さてこのエントリの本題はここからで、CSRFトークンよりもむしろセッションIDの方です。最近は443番ポートへクロスサイトでリクエストを大量に送らせてそれをキャプチャし、すべてのリクエストに共通して含まれてくるCookie中のセッションIDを解読するBEAST/CRIME系の攻撃が知られるようになりました。 これらは基本的にはTLS/SSLの問題でありそれぞれ個別に対策が存在しているものの、基本的には「セッションIDがず
VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について - debiruはてなメモ
2015年12月に私が発見した VALUE-DOMAIN での CSRF 脆弱性について、その脆弱性の報告と修正までの経緯を記しておきます。 きっかけ アカウント削除ページの作り アカウント削除ページの問題点 VALUE-DOMAIN への報告 CSRF 攻撃によるアカウント乗っ取りの問題 IPA への届出 余談：IPA への届出の仕方について IPA へ届出した後の状況 VALUE-DOMAIN ユーザの方へ きっかけ 数年前に VALUE-DOMAIN を利用していましたが最近は使っていないのでアカウントを削除しようとしたところ、アカウント削除操作を行うページの作りが「不自然である」ことに気付きました。更に調べたところ CSRF 攻撃によってアカウント乗っ取りが可能な状況であることが分かりました。 アカウント乗っ取りが可能な CSRF 脆弱性は2015年12月22日にIPAに報告し、2
XSSやCSRFリスクを軽減する、Entry Point Regulationとは - ASnoKaze blog
Entry Point Regulation とは 反射型XSS・XSSI・CSRFのリスクを軽減するユーザエージェント上の仕組みとして、W3CでEntry Point Regulationという仕様が策定中です。 Webアプリケーションの口(Entry Point)に幾つかの制限をかけることが出来ます。別オリジンからのリクエストの時に、クエリパラメータやHTTPリクエストボディ(POSTメソッド)が付いていればブロックする、と言った事がマニフェストで指示できるようになりそうです。 EPRにおけるリクエストカテゴリ 各エンドポイント(URL)はどのようなリクエストを受け付けることが可能か指定できます。その時に指定するリクエストは以下に分類されます navigational request：context frame typeは"top-level", "auxiliary", "neste
リクエストフォージェリを再考 – リクエストのインジェクションと考える
Last Updated on: 2018年8月8日リクエストフォージェリを再考してみたいと思います。リクエストフォージェリには SSRF（サーバーサイドリクエストフォージェリ） CSRF（クロスサイトリクエストフォージェリ） XXE(XMLエクスターナルエンティティ） などがあります。これらは「リクエスト」を「偽装」（フォージェリ）する攻撃です。名前からは直感的にどのような攻撃なのかよく解らないですが、「攻撃リクエストのインジェクション」と考えると解りやすいと思います。 リクエストフォージェリとは？ リクエストフォージェリとは偽装したリクエストを正当なリクエストとして処理してしまう問題です。この問題は古いUNIX系システムで利用されていたリモートシェル（rコマンドと呼ばれていた）を利用した場合に発生することが広く認識されていました。 セキュリティ標準的には「真正性」（Authentici
書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性について追試してみた — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
以下の記事よると、書籍『Webアプリケーションセキュリティ対策入門』のサンプルにCSRF脆弱性があるということなので、確認してみることにしました。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記 サンプルのインストール まず、Webアプリケーションセキュリティ対策入門の付録を更新 | yohgaki's blogよりサンプルコードsimple-bbs.tar.bz2をダウンロードします。 展開し、データベースを作成します。 $ tar xvf simple-bbs.tar.bz2 $ (cd simple-bbs/dat/install/; php initdb.php) データベースを作成：/Users/kenji/tmp/simple-bbs/dat/bbs.dat form_idテーブルを作成しました。 userテーブルを作成しました。 thre
Endpoint Protection - Symantec Enterprise
過去数カ月、ソーシャルネットワークサイトへと誘導しようとするさまざまなスパム攻撃が確認されています。これらの攻撃のほとんどは、何らかのソーシャルエンジニアリング手法の特徴を備えていますが、ときとして、画期的なソーシャルエンジニアリング手法も登場しています。ここでは、そうした手法のなかでも、Facebook で特に重要な CSRF 対策トークンを盗み出そうとしてユーザーを欺く手口を紹介します。 クロスサイトリクエストフォージェリ攻撃 クロスサイトリクエストフォージェリ（CSRF）とは、ある Web サイトで認証済みのセッションを再利用して、ユーザーに気づかれないまま、または同意を得ずにその Web サイトで悪質な処理を実行する攻撃です。たとえば、ユーザーが自分のオンラインバンキングのサイトにログインしているとします。この Web サイトに CSRF の脆弱性があると、別の悪質な Web サイ
クロスサイトリクエストフォージェリ(CSRF)とその対策
本資料は、web アプリケーションにおける脆弱性のひとつ、CSRF (クロスサイトリクエ ストフォージェリ) の仕組みとその対策に関する説明資料です。 また、CSRF 対策のためのライブラリのいくつかについて、その概要と適用例も紹介しています。 Webアプリケーションを作成する開発者の方々が、CSRF 脆弱性に対する理解を深め、よりセキュアなWebアプリケーションの開発の一助となれば幸いです。 自習用の資料や勉強会での資料としてご活用ください。 - 改訂版+1: 図版や誤記の修正 (2015年10月20日) ※ コメントくださった皆様ありがとうございます! - 改訂版: JPCERT/CC Web サイトにて公開 (2015年10月6日) - 初版: OSC2015Hokkaido 講演資料 (2015年6月13日)
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Send AJAX request with CSRF token in CodeIgniter 4 - Makitweb
GitHub - Ocramius/PSR7Csrf: PSR-7 storage-less CSRF token generation/validation
CodeIgniter: ignore CSRF in many URIs
クロスサイトリクエストフォージェリ(CSRF)とその対策
GitHub - paragonie/anti-csrf: Full-Featured Anti-CSRF Library
Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話
