PHPerKaigi 2024 • Day 1での登壇資料です。 https://phperkaigi.jp/2024/ https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f ※ Authorizationヘッダーを利用したBearerトークン等の活用については言及していません。
![CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection](https://cdn-ak-scissors.b.st-hatena.com/image/square/16941b80c8ebaf4eb666f4fc7709aea8dcca2b34/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F3b096a2496354773a9e2a6184240db8b%2Fslide_0.jpg%3F29217169)
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
ドラえも⚫︎で理解するCSRF はじめに ※コメントにて徳丸浩先生(@ockeghem)に間違いをいくつかご指摘頂き修正中です。 また、@rudorufu1981様よりブラウザの同一オリジンポリシーについての補足を頂いております。 ぜひ記事の下部、コメント欄までご覧頂きますようお願いいたします。 ご指摘や補足、本当に有難うございます。 【追記2023.12.2】 同一オリジンポリシーの補足についても徳丸先生のご見解コメントを頂いております。ぜひそちらもご確認下さい。 【追記2023.12.5】 ご指摘を受けて同一オリジンポリシーはCSRFと直接の関連はない事から、取り消し線にて削除致しました。 対象読者 ・HTTPの特性 ・セッション管理 ・ブラウザの同一オリジンポリシー ・CSRF(Cross-Site Request Forgeries) ⚫︎上記の言葉を聞いてイメージができない人 ⚫
ふと気になって調べたことの備忘メモです ✍ (2022/11/3追記)ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く