タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection
PHPerKaigi 2024 • Day 1での登壇資料です。 https://phperkaigi.jp/2024/ https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f ※ Author…
CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
サマリ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にて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
こんにちは @zaru です。今回は昔からある CSRF (クロスサイト・リクエスト・フォージェリ) の今時の対策についてまとめてみました。もし、記事中に間違いがあれば @zaru まで DM もしくはメンションをください (セキュリティの細かい部分についての理解が乏しい…) 。 2022/08/29 : 徳丸さんからフィードバック頂いた内容を反映しました。徳丸さん、ありがとうございます！ 認証あり・なしで対策方法が違う点 トークン確認方式のデメリットのクロスドメインについての言及を削除、代わりに Cookie 改変リスクを追記 Cookie 改ざん可能性について徳丸さんの動画リンクを追記 SameSite 属性で防げない具体的なケースを追記 nginx 説明が関係なかったので削除 そもそも CSRF ってなに？ 昔からインターネットをやっている方であれば「ぼくはまちちゃん」 騒動と言えば
ふと気になって調べたことの備忘メモです ✍ （2022/11/3追記）ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
こんにちは、 @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対策 - Qiita
はじめに WEBエンジニアとして成長するために、セキュリティ対策は避けては通れない道ですよね。 僕も含め 「なんとなく知ってる」 という方は多いのではないでしょうか。 大切なWEBサイトを守るためにも、WEBエンジニアとしての基礎を固める為にも、しっかりと学んで一緒にレベルアップしていきましょう。 また、本記事の内容は様々な文献をもとに自身で調べ、試したものをまとめています。 至らぬ点や、間違いがありましたら、コメントにてご指摘をお願いします。 他にも様々な攻撃手法についてまとめているので、興味のある方は読んでみてください。 攻撃から学ぶXSS対策 攻撃から学ぶSQLインジェクション対策 CSRFって何？ CSRF（Cross-Site Request Forgery）とは、サービスの利用者に意図しないHTTPリクエストを送信させ、意図しない処理を実行させる攻撃手法です。 これだけでは分か
技術記事は はてなブログ へお引越ししました。 興味を持ってくださった方はZennではなくこちらをご購読いただければと思います🙏 誰しもLaravelのbladeでformを書くにあたって、@csrfという魔法の呪文を書いたことがあるかと思います。 「これを書いておけばCSRF対策はOK」 ドキュメントにも要約するとそういう旨が書いてあります。 この記事では@csrfについてLaravelの実装を実際に見てみることで、CSRFとその対策への理解を深めたいと思います。 ちなみにこの記事はぺちこん2024で残念ながら採択に至らなかったCfPの供養です。[1] 利用するサンプルアプリ @csrf はなにをしているのか？ そもそもですが、@csrfが何をしているのかを見てみます。 bladeに@csrfを埋め込んだ場所を、HTML変換後の状態から見てみます。 <input type="hidde
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ドラえも⚫︎で理解するCSRF はじめに ※コメントにて徳丸浩先生(@ockeghem)に間違いをいくつかご指摘頂き修正中です。 また、@rudorufu1981様よりブラウザの同一オリジンポリシーについての補足を頂いております。 ぜひ記事の下部、コメント欄までご覧頂きますようお願いいたします。 ご指摘や補足、本当に有難うございます。 【追記2023.12.2】 同一オリジンポリシーの補足についても徳丸先生のご見解コメントを頂いております。ぜひそちらもご確認下さい。 【追記2023.12.5】 ご指摘を受けて同一オリジンポリシーはCSR
With an increasing number of breaches, intrusions, and data thefts, securing a web application is extremely important. On the other hand, programmers often do not have a strong grasp of how attacks work and how to mitigate them. This post attempts to close that gap a little. CSRF Cross-Site Request Forgery is an attack where a third party forces a user to execute actions against a site where they
Rails API + SPAのCSRF対策例
2024.10.26 この記事はもう内容が古いので参照しなくて良いです。 これからは以下の記事を参考にしてください。 https://speakerdeck.com/corocn/kaigionrails-2024-csrf Leaner Technologies の @corocn です。 本記事では Ruby on Rails の基本的な CSRF 対策の方法である "Synchronizer Token Pattern" を Rails API + SPA の構成でどう実装するかについてお伝えします。 CSRF 対策について解説した記事は多くありますが、最近直面したユースケースに沿った記事がなかったので、改めて整理しておくと誰かの役にたつかなと思ったので書きました。 前提 次のようなシンプルな構成のシステムを考えます。 ログインして操作するシステム Cookie と Session
Web Security 101: An Interactive Cross-Site Request Forgery (CSRF) Demo - victorzhou.com
Looking for an introduction to Cross-Site Request Forgery (CSRF)? This post will be a little different - instead of telling you what it is, I’m going to show you. Ready? Setting the Scene You’re a responsible, hardworking person. You’ve saved up your money over the years at Definitely Secure Bank®. The Definitely Secure Bank logo. You love Definitely Secure Bank - they’ve always been good to you,
Ruby on Rails を API として、フロントエンドとの間で通信をしようとしたところ、 セッションが保存されなかったり、Can't verify CSRF token authenticity というエラーが出てくることがあります。 多くのページでは解決方法として CSRF 対策をあきらめていますが、 ここではちゃんとしたセキュアな解消方法について書いていきます。 エラーも出ないがセッションが保存されないときこの記事にもあるように、CSRF という攻撃からサイトを守るために、 Rails はリクエストが不正でないか確認できないとセッションを空にしてしまいます。 エラーも出ないのでわかりづらいですが、 application_controller.rb に protect_from_forgery with: :exception を記述すると Can't verify CSRF
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 前提条件 この脆弱性を攻撃するには、攻撃者が攻撃対象のサイトと同じドメインのサブドメインサイトを支配下に置いている必要があります。 簡単に言えば、サブドメインサイトのページを書き換えられるということです。これはそのサ
記事の趣旨 モダンなWebアプリ開発の学習として、Vue.jsによるフロント、Rails APIによるバックエンドで実装するSPAを作りました。 その中で、SPAの様々なログイン実装方法や、それに必要な CSRF 対策を学びました。 最終的に session + cookie を利用するログインを実装した過程を記録したいと思います。 ログイン実装方法の検討 SPAのログイン実装方法 下記の記事等を読んで、主に JWT を使う方法と、 session を使う方法があることが分かりました。 SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 上の記事では、様々な方法の良し悪しが網羅的にまとめられていました。 JWT・Cookieそれぞれの認証方式のメリデメ比較 上の記事では、JWTとCookieが端的に比較されていま
モノリス(MPA)だと、CSRF 対策として CSRF トークンを置いて検証するのが主流で、だいたいフレームワークに実装されてる機能を使うけど、SPA だと HTML は静的にビルドされるので、トークンを埋め込むことができない 埋め込むなら SSR をすることになるけど、BFF と API サーバーは一般に別なので、トークンの管理が大変 セッションを管理したいのは API サーバー (CSRF トークンはセッションに置いて API 呼び出し検証する必要があるので) だけど、CSRF トークンを set-cookie できるのは BFF のサーバーなので色々大変。考えたくない まずもって(他の理由で SSR する必要があるならともかく) SSR もしたくないし 埋め込みではなく、ページロード後に API サーバーに CSRF トークンを問い合わせる案 一応できなくはないけど、読み込み時の状態
週刊Railsウォッチ（20200616後編）本番環境をFullstaq Rubyに換えた理由、CSRF発生フローチャート、DBのトランザクション分離レベル比較ほか｜TechRacho by BPS株式会社
morimorihoge注：本トピックに関するコメントとして、初出時人種差による不平等を容認・揶揄するようにも取れる内容がありましたので当該部分を削除させていただきました。 Twitter上でのご指摘を受けて社内ヒアリングを行ったところ、私を含む参加メンバーで主題の認識違いがあり、主題のすれ違いの中話していた内容をテキスト化した際に公開記事として掲載するにあたって不適切な内容となってしまっていたことが判明いたしました。不快に感じられた方にはこの場を借りてお詫びいたします。 ※BPS株式会社は会社・組織として人種その他先天的・後天的な要因による差別を容認・支持する立場にはありません（弊社代表にも確認済み） 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会
安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
ログイン後の利用者のみが利用可能なサービスの悪用 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理 等 ログイン後の利用者のみが編集可能な情報の改ざん、新規登録 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み 等 注意が必要なウェブサイトの特徴 次の技術を利用してセッション管理を実装しているウェブサイトが、CSRF攻撃による影響を受ける可能性があります。 Cookieを用いたセッション管理 Basic認証 SSLクライアント認証 また、上記を実装するウェブサイトのうち、ログイン後に決済処理等の重要な処理を行うサイトは、攻撃による被害が大きくなるため、特に注意が必要です。 届出状況 CSRFの脆弱性に関する届出が、ウェブサイトの届出全体に占める割合は、1パーセント未満と多くはありません。しかしながらこれらの脆弱性については、ソフトウェア製品の届
DjangoとReactによる、CSRF対策と注意点 | Tech ブログ | サーバ運用保守・運用監視なら JIG-SAW OPS
本記事のポイント CSRF（クロスサイトリクエストフォージェリ）とは、Webアプリケーションに存在する脆弱性、もしくはその脆弱性を利用した攻撃方法であり、サイバー攻撃の１つです。 本記事では、DjangoとReactを用いたCSRF対策の方法を、注意すべきポイントと合わせてご紹介します。実装に使用するコードも載せておりますので、ぜひご覧ください。 はじめに Django（ジャンゴ）とは、Pythonで動作するWebアプリケーションフレームワークです。機能的な独立性の高さ故に、メンテナンスが容易で、効率的にアプリケーションを作れることから多くのユーザに使われています。 しかし、Djangoに標準搭載されているテンプレートエンジンではスケールが難しく、しばしばフロントエンドが他のフレームワークに置き換えられる事例が見られます。 Djangoに標準搭載されているCSRF対策機能は、Djangoの
クロスサイトリクエストフォージェリ（Cross-Site Request Forgeries）は、Webアプリケーションのサーバー側機能を、ユーザーの意図に反して勝手に実行させる攻撃です。被害を与えるWebサイトの掲示板などに、ユーザーのパソコンのIPアドレスでアクセスして悪意のある書き込みを実施したりします。 略称として「CSRF」と表記する場合もあります。 ユーザーの意図しない情報・リクエストが送信されてしまうため「リクエスト強要」とも呼ばれます。 クロスサイトリクエストフォージェリの例この対策の方法として、リクエストの照合を強化することがあります。CSRFはユーザーに意図しないリクエスト送信を強要するものですので、リクエスト送信が、正しく送られたものかどうかをサーバー側でチェックし、正しいリクエストの場合のみ処理することでCSRF攻撃を防ぐことができます。 リクエスト照合でよく使われ
概要 CookieにSameSite属性を付与することで、CSRF脆弱性1に対していくらかの防御ができる。 SameSite属性はStrict,Lax,Noneの3つの値を取り、設定値により効果の範囲は異なる Strictを設定することで、CSRFを防げる。ただし、Webサイトの使いやすさが損なわれる場合がある Laxを設定することで、POSTメソッドのリクエストのみを受け付ける処理でCSRFを防げる None は従来通りの動作であり、外部サイトからCookieを送信する Webサイトのセキュリティ要件により、設定すべき値が異なる SameSite属性は主要なブラウザすべてで対応されている SameSite属性の付与がCSRF脆弱性への防御とならないケース Windows 10 RS3（2017 Fall Creators Update）未満のIE 11など、SameSite属性をサポート
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 の発表資料です
クロスサイト･スクリプティング（XSS）とクロスサイト･リクエスト･フォージェリ（CSRF）の違い | サイバーセキュリティ情報局
インターネットの普及により、私たちはWebサイト上でさまざまなサービスを受けることが可能になった。その一方で、こうしたWebアプリケーションの脆弱性を狙った攻撃は年々増加している。本記事では、その中でも古典的ながら今なお代表的な脆弱性で、混同されがちなクロスサイト・スクリプティング（XSS）と、クロスサイト・リクエスト・フォージェリ（CSRF）について、改めて仕組みの違いや過去の被害事例、対策を整理し紹介する。 クロスサイト･スクリプティング（XSS）とは 2019年10月24日に独立行政法人情報処理推進機構（IPA）が発表した報告資料によると、2019年第3四半期におけるWebサイト脆弱性に関する届け出件数は278件。そのうち、約58％をクロスサイト・スクリプティング（以下、XSS）が占めている。脆弱性はセキュリティホールとも呼ばれ、アプリケーションのプログラムの不具合や設計ミスによって
本記事は 【Advent Calendar 2023】 11日目の記事です。 🎄 10日目 ▶▶ 本記事 ▶▶ 12日目 🎅 はじめに こんにちは、去年の11月に中途入社した上村です。転職してから1年となり、時間が経つのが早いと感じます... 私はSpring Bootを用いたWebアプリケーションに業務で携わっています。その中で、CSRF（クロスサイトリクエストフォージェリ）という脆弱性に触れる機会がありました。Spring Securityの機能により、CSRF対策が簡単にできることを学んだので、紹介していきます。 CSRFとは CSRFとは、Webアプリケーションの脆弱性の一つです。本来拒否すべきリクエストを受信して処理してしまう脆弱性、もしくはその脆弱性を突く攻撃を表します。 通販システムを例として説明します。この通販システム向けの攻撃用サイトを攻撃者が予め用意しておきます。正
ギークフィードエンジニアの君島です。Laravelを始めて1年目、自動テストを始めて7年目になります。 今回はCSRF保護対策を実装したLaravel5.6環境をJMeterでテストするための最低限必要な設定方法を記載します。 CSRF対策している前提なので、CSRF例外のRouteに加えた後にテストするというのは無しです。 LaravelのCSRF対策のドキュメントに基づいて、リクエストパラメータを設定しました。 正規表現を使用して直前のレスポンスから値を抽出する方法や、 実際に動作したシナリオとなるテストプランの構成も記載しました。 CSRF対策後の419Unknown statusを解決したい JMeterでテストしていたが、CSRF対策をしたところ419 Unknown statusが返るようになった！ 自動テストの観点でのLaravel環境の記事が少なく、自分で調べることにしまし
Next.jsでのCSRF対策方法を教えてください
1import Layout from "../components/layout" 2import Tags from "./tags" 3import SearchWindow from "./search_window" 4import { getUniqTags } from "../lib/posts" 5import axios from 'axios' 6 7export async function getStaticProps() { 8 9 const uniqTags = getUniqTags() 10 11 return { 12 props:{ 13 uniqTags 14 } 15 } 16 17} 18 19const submitFormData = (e) => { 20 e.preventDefault() 21 22 axios.post('/api
Easy CSRF bypass
Greetings to the reader, I hope you are doing well. Today I want to talk about one of my findings in a private program at Hacker-One platform, which refers to it as target.com. Firstly:Following some reconnaissance and effort, I found target.com, I create an account on it and tried to understand the application and its functionalities in it. I tried to test a lot of things, but I was unable to ide
<form action="https://bank.example.com/transfer" method="post"> <input type="hidden" name="to" value="cracker" /> <input type="hidden" name="amount" value="¥10000000" /> <button>今すぐクリック！！！</button> </form> 問題は何の関係性もないmalicious.example.comのサイトから発せられたbank.example.comへのリクエストにbank.example.comの認証情報（Cookie）が付与されてしまうことです。これによってbank.example.comに対するユーザ認証付きの操作を第三者がそれと分からない形で実行させることができてしまうわけです。 そこで導入されたのがSet
この記事はSPA + WEB_APIで構築するWEBサービスのセキュリティの脆弱性を考える時に必ず出てくる、CSRF対策やCORSの考察をした記録です。 SPAでWEBサイトを構築する方、または既に持っていて脆弱性がないか調べている時にお役に立てる内容となります。 CSRFについてはこちらのサイトがとてもわかりやすいです。 https://qiita.com/okamoai/items/044c03680766f0609d41 大前提 ブラウザで非同期通信を行う際には、同一生成元ポリシー(Same Origin Policy)によってWebページを生成したドメイン以外へのHTTPリクエストができません。 SPA + WEB_APIのパターンなど異なるドメインのリソースにアクセスしたいという需要があります → 昔はJSONP使ってたがセキュリティだめ → より手軽に、より安全にクロスドメイン
Protecting Next.js apps from CSRF attacks - LogRocket Blog
Using HTTP-only cookies By setting the HttpOnly cookie flag, you can reduce the likelihood of a CSRF attack since HTTP-only cookies cannot be retrieved by JavaScript through client-side scripts. res.setHeader("Set-Cookie", `session=${sessionId}; Path=/; Max-Age=600; SameSite=Strict; HttpOnly`); Using CSRF tokens One way to protect your web application against a CSRF attack is to use CSRF tokens. A
CSRF攻撃の仕組みと対策
脆弱性が蔓延し、絶えず増え続ける今日、ユーザーのセキュリティとプライバシーの保護は、これまで以上に重要視されています。脆弱性を見過ごせば、評価が失墜したり、高額な制裁金を科されたり、顧客や訪問者からの信頼を失ったりする可能性が高まります。 ウェブサイトやウェブアプリケーションは、常にマルウェアやスパムなどの攻撃の危険に晒されています。今回は、そんな攻撃の1つであるCSRF（クロスサイトリクエストフォージェリ）に焦点を当てます。CSRF攻撃は、気づかない間に発生する可能性があり、特に問題視されています。また悪意のある要求は正しい要求と区別が難しく、開発者やサイト運営者が発見しづらいというのも厄介です。 この記事で、CSRF攻撃の概要と仕組み、そして対策について学びましょう。 CSRF攻撃について動画での解説もご用意しています。 CSRF攻撃とは クロスサイトリクエストフォージェリは、略してC
「でもこれだけだと、不正なフロントエンドからもアクセスできちゃうんじゃないですか？偽物のフロントエンドにもトークンを要求する実装をしておけば、バックエンドへアクセスできるようになっちゃうんじゃないですか？」と。 あれれ？たしかに(・∀・；)・・・いやいや、違いますよ！ バックエンドに正規のフロントエンドの情報が設定されているのが肝 ここで重要なのは、CSRFトークンは正規のフロントエンドかどうかをチェックしてから返されるという点です。 誰ふり構わずCSRFトークンを返していては、質問のとおり、まったく意味がありません。偽物フロントエンドからのトークン要求にも答えてしまっては、不正なフロントエンドからもバックエンドへアクセスできてしまいます。これではトークンの意味がないですよね。 なので、バックエンドはCSRFトークンを要求されると、正規のフロントエンドから要求されているかを確認するようにし
React.jsとExpress.js（Node.js）で独自のCSRF対策を実装する | Neightbor. | あなたのビジネスをWEBで支える
Webシステムを構築する際にセキュリティ対策として懸念すべき点がいくつかあります。 その一つが、CSRF（クロスサイト・リクエスト・フォージェリ）対策です。 今回は、React.js（フロントエンド）とExpress.js（バックエンド）の構成で独自のCSRF対策を実装する方法をまとめて行きます。 CSRF（クロスサイト・リクエスト・フォージェリ）とは 本題に入る前に今回対策するCSRF攻撃とはどのようなものなのかを簡単に説明します。 よくあるユーザ登録や掲示板の機能などで、【フォームへの入力】→【データベースへの登録処理】→【データベースへの書き込み実行】というフローがある状況で考えていきます。 想定されるプロセスとしては、登録フォームの入力画面に表示されている項目を入力し、その内容をプログラム部分が受け取り、データベースへのアクションを行います。 このプロセスの範囲であれば入力される内
クロスサイトスクリプティング(XSS)脆弱性を用いて、CSRF攻撃のように更新系処理を悪用することができます。この場合、CSRF対策のトークンなどは突破されてしまいます。 XSSによる更新系機能への攻撃は一見するとCSRF攻撃と似ていますが、中身は違っているため、CSRF攻撃用の対策（下記）はXSS攻撃に対しては無力です。 ・CSRFトークン ・Refererチェック ・CookieのSameSite=Lax指定 ・Double Submit Cookie ・カスタムリクエストヘッダ なぜそうなるのか、原理のところから詳しく解説します。 本動画では、XSSのデモはありませんが、デモをご覧いただきたい方は、以下の動画の後半にて解説しています。 ・クロスサイトスクリプティング(XSS)対策としてCookieのHttpOnly属性でどこまで安全になるのか https://www.you
ログイン時のCSRF対策は必要か - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん！(Hatena) を読んでの噛み砕きです。 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対策する、みたいな。 まさにイメージがこれだったので。 結論 (結論) ログインのフォームもCSRF対策したほうがいいよ。 被害が出るかはユーザーの気を付け方次第。 被害の大きさはサービスの性質・ユーザーのアウトプットの内容次第。 「閲覧専用」のようなサービ
環境 Nextjs 13 edge-csrf 1.0.3-rc1 TypeScript 5 やりたいこと 今日は、Next.jsの開発について書こうと思います。Next.jsは、開発がとても便利であることがよく知られています。 しかし、CSRFトークンの機能がRailsのようにネイティブで用意されていないため、自分で実装する必要があります。 これは面倒ですが、edge-csrfというライブラリを使えば簡単にCSRFトークンの実装ができます。先日、私自身もこのライブラリを使ってCSRFトークンの実装を行い、スムーズに開発を進めることができました。 今回はそのメモ https://github.com/amorey/edge-csrf インストール npm install edge-csrf yarn add edge-csrf ミドルウェアの追加 APIのエンドポイントごとにCSRFの実装す
Close Look at CSRF Tokens
Cross-site request foregery is one of many techniques an attacker might use to pwn a web application. In this article we take a close look at how exactly CSRF tokens work from the context of the Phoenix Web Framework. I set out to understand how CSRF tokens are generated and validated. I did it by tracing the flow of function calls through a Phoenix web applciation. It was a process that led me do
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか
今時の CSRF 対策ってなにをすればいいの？ | Basicinc Enjoy Hacking!
CSRF(Cross-Site Request Forgery)攻撃について
LaravelはどのようにCSRF対策をしているのか？
ドラえも⚫︎で理解するCSRF - Qiita
CSRF, CORS, and HTTP Security headers Demystified
【Rails API】CSRF 対策をあきらめないでちゃんとやる | みどりみちのブログ
【Rails API + SPA】ログイン方法とCSRF対策例 - Qiita
SPA + WebAPI でアプリケーションを構築するときの CSRF 対策についてのメモ
クロスサイトリクエストフォージェリ（ＣＳＲＦ）：気になる情報セキュリティ用語 - 叡智の三猿
SameSite属性の付与によるCSRF脆弱性対策 - Qiita
Spring Securityで簡単にCSRF対策ができる - NRIネットコムBlog
CSRF保護対策したLaravel5.6環境でのJMeterの使い方 | ソフトウェア開発のギークフィード
CSRFトークンはもはや不要です - Qiita
SPA + WEB API のCSRF対策とCORSについて - Qiita
CSRFトークンってなんの意味があるの？意外と知らないAPI通信におけるCSRFの仕組み
XSS脆弱性があるとCSRF対策は突破できる | YouTube
Next.jsでCSRF対策を簡単に実装する方法 - 動かざることバグの如し
TDU学生、WordPress用プラグインWP Sticky SocialにおけるCSRF脆弱性発見 | ScanNetSecurity
【Rails7】Ajaxリクエスト時にCSRF tokenを含める（おそらく）公式のやり方 - Qiita
www.tokyodisneyresort.jp
anond.hatelabo.jp
blog.goo.ne.jp/sikyakuhaiku
news.yahoo.co.jp
happy-w-n.com
panasonic.jp