タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
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
こんにちは @zaru です。今回は昔からある CSRF (クロスサイト・リクエスト・フォージェリ) の今時の対策についてまとめてみました。もし、記事中に間違いがあれば @zaru まで DM もしくはメンションをください (セキュリティの細かい部分についての理解が乏しい…) 。 2022/08/29 : 徳丸さんからフィードバック頂いた内容を反映しました。徳丸さん、ありがとうございます！ 認証あり・なしで対策方法が違う点 トークン確認方式のデメリットのクロスドメインについての言及を削除、代わりに Cookie 改変リスクを追記 Cookie 改ざん可能性について徳丸さんの動画リンクを追記 SameSite 属性で防げない具体的なケースを追記 nginx 説明が関係なかったので削除 そもそも CSRF ってなに？ 昔からインターネットをやっている方であれば「ぼくはまちちゃん」 騒動と言えば
攻撃から学ぶCSRF対策 - Qiita
はじめに WEBエンジニアとして成長するために、セキュリティ対策は避けては通れない道ですよね。 僕も含め 「なんとなく知ってる」 という方は多いのではないでしょうか。 大切なWEBサイトを守るためにも、WEBエンジニアとしての基礎を固める為にも、しっかりと学んで一緒にレベルアップしていきましょう。 また、本記事の内容は様々な文献をもとに自身で調べ、試したものをまとめています。 至らぬ点や、間違いがありましたら、コメントにてご指摘をお願いします。 他にも様々な攻撃手法についてまとめているので、興味のある方は読んでみてください。 攻撃から学ぶXSS対策 攻撃から学ぶSQLインジェクション対策 CSRFって何？ CSRF（Cross-Site Request Forgery）とは、サービスの利用者に意図しないHTTPリクエストを送信させ、意図しない処理を実行させる攻撃手法です。 これだけでは分か
Rails API + SPAのCSRF対策例
Leaner Technologies の @corocn です。 本記事では Ruby on Rails の基本的な CSRF 対策の方法である "Synchronizer Token Pattern" を Rails API + SPA の構成でどう実装するかについてお伝えします。 CSRF 対策について解説した記事は多くありますが、最近直面したユースケースに沿った記事がなかったので、改めて整理しておくと誰かの役にたつかなと思ったので書きました。 前提 次のようなシンプルな構成のシステムを考えます。 ログインして操作するシステム Cookie と Session ID でセッション管理をするステートフルな API SPA からのリクエストは axios を利用 Rails の強みを生かし、小さく立ち上げたいときにありがちな構成です。Cookie を利用するため、CSRF 対策が必要にな
記事の趣旨 モダンなWebアプリ開発の学習として、Vue.jsによるフロント、Rails APIによるバックエンドで実装するSPAを作りました。 その中で、SPAの様々なログイン実装方法や、それに必要な CSRF 対策を学びました。 最終的に session + cookie を利用するログインを実装した過程を記録したいと思います。 ログイン実装方法の検討 SPAのログイン実装方法 下記の記事等を読んで、主に JWT を使う方法と、 session を使う方法があることが分かりました。 SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 上の記事では、様々な方法の良し悪しが網羅的にまとめられていました。 JWT・Cookieそれぞれの認証方式のメリデメ比較 上の記事では、JWTとCookieが端的に比較されていま
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
モノリス(MPA)だと、CSRF 対策として CSRF トークンを置いて検証するのが主流で、だいたいフレームワークに実装されてる機能を使うけど、SPA だと HTML は静的にビルドされるので、トークンを埋め込むことができない 埋め込むなら SSR をすることになるけど、BFF と API サーバーは一般に別なので、トークンの管理が大変 セッションを管理したいのは API サーバー (CSRF トークンはセッションに置いて API 呼び出し検証する必要があるので) だけど、CSRF トークンを set-cookie できるのは BFF のサーバーなので色々大変。考えたくない まずもって(他の理由で SSR する必要があるならともかく) SSR もしたくないし 埋め込みではなく、ページロード後に API サーバーに CSRF トークンを問い合わせる案 一応できなくはないけど、読み込み時の状態
SPA(Vue + RailsAPI)で何とかログイン認証機能 + CSRF対策を実装したので、ブログにメモしておきます。 実装の概要 使用した技術たち JWT(JsonWebToken) アクセストークン、リフレッシュトークンって？ WebStorage JWTSession 遷移の概要(より正確な内容は要Gem参照) トークンストアの設定 バックエンド側の仕事 Signinコントローラー フロントエンド側の仕事 axiosのインスタンスの作成 main.jsでインスタンスの読み込み インスタンスの使用方法 ただ、ブラウザによって上手く動作しないものが… 3rd party cookiesとは？ 余談 実装の概要 今回は、JWT + (WebStorage + Cookie）を使って実装しました。（後に用語説明します） WebStorageとJWTによるセッションの管理（ログイン状態の管
こんばんは、OAuth👮♂️です。 緊急事態宣言、外出自粛、みなさまどうお過ごしでしょうか？ お家に高い椅子と4KディスプレイとYouTuber並みのマイクを準備し、ようやくOAuth/OIDCを用いたID連携機能の実装に手をつけられるようになった頃かと思います。 本日はID連携時のCSRF対策について、動くものがある状態からのチェックの方法を紹介します。 手元で開発したサービスの登録とかログインにソーシャルログイン機能をつけて「おっ、IdPと繋がった！」ってなったら、Qiitaにその手順を晒すまえにこういうのを試してみましょう。 IdPに遷移する時のURLを確認する ライブラリとかで作る場合は、登録もログインも既存アカウントへの連携も同じような処理が行われるはずです。 なのでだいたいどこでも良いと思います。 ※画像はイメージです ※画像はイメージです Googleでログイン機能とかを
DjangoとReactによる、CSRF対策と注意点 | Tech ブログ | サーバ運用保守・運用監視なら JIG-SAW OPS
本記事のポイント CSRF（クロスサイトリクエストフォージェリ）とは、Webアプリケーションに存在する脆弱性、もしくはその脆弱性を利用した攻撃方法であり、サイバー攻撃の１つです。 本記事では、DjangoとReactを用いたCSRF対策の方法を、注意すべきポイントと合わせてご紹介します。実装に使用するコードも載せておりますので、ぜひご覧ください。 はじめに Django（ジャンゴ）とは、Pythonで動作するWebアプリケーションフレームワークです。機能的な独立性の高さ故に、メンテナンスが容易で、効率的にアプリケーションを作れることから多くのユーザに使われています。 しかし、Djangoに標準搭載されているテンプレートエンジンではスケールが難しく、しばしばフロントエンドが他のフレームワークに置き換えられる事例が見られます。 Djangoに標準搭載されているCSRF対策機能は、Djangoの
本記事は 【Advent Calendar 2023】 11日目の記事です。 🎄 10日目 ▶▶ 本記事 ▶▶ 12日目 🎅 はじめに こんにちは、去年の11月に中途入社した上村です。転職してから1年となり、時間が経つのが早いと感じます... 私はSpring Bootを用いたWebアプリケーションに業務で携わっています。その中で、CSRF（クロスサイトリクエストフォージェリ）という脆弱性に触れる機会がありました。Spring Securityの機能により、CSRF対策が簡単にできることを学んだので、紹介していきます。 CSRFとは CSRFとは、Webアプリケーションの脆弱性の一つです。本来拒否すべきリクエストを受信して処理してしまう脆弱性、もしくはその脆弱性を突く攻撃を表します。 通販システムを例として説明します。この通販システム向けの攻撃用サイトを攻撃者が予め用意しておきます。正
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
エンジニアリング部システムソリューション課のひよっこエンジニアKと申します。エンジニアになってまだ2ヶ月強の私は、課題や仕事に取り組む中でわからないことにぶち当たることが多いです。この記事は、わからないところについて調べた結果などをまとめています。 今回のテーマは、CSRF対策についてです。今回課題をやっていて苦戦したところ等を主に書いていきます。まだまだ調べが足りない点も多いので、随時更新予定です。 そもそもCSRF(クロスサイト・リクエストフォージェリ)とは何なのか？ Webアプリケーションにはログインした利用者のアカウントにより、取り消せない重要な処理(利用者のクレジットカードでの決済や、利用者の口座からの送金、メール送信、パスワードやメールアドレスの変更など)が実行できるものがあります。『安全なWebアプリケーションの作り方（第2版）』によると、CSRF攻撃は利用者のブラウザから罠
この記事はSPA + WEB_APIで構築するWEBサービスのセキュリティの脆弱性を考える時に必ず出てくる、CSRF対策やCORSの考察をした記録です。 SPAでWEBサイトを構築する方、または既に持っていて脆弱性がないか調べている時にお役に立てる内容となります。 CSRFについてはこちらのサイトがとてもわかりやすいです。 https://qiita.com/okamoai/items/044c03680766f0609d41 大前提 ブラウザで非同期通信を行う際には、同一生成元ポリシー(Same Origin Policy)によってWebページを生成したドメイン以外へのHTTPリクエストができません。 SPA + WEB_APIのパターンなど異なるドメインのリソースにアクセスしたいという需要があります → 昔はJSONP使ってたがセキュリティだめ → より手軽に、より安全にクロスドメイン
以前、Ruby on Rails の API モードでアプリを作成しました。 Ruby on Rails で API サーバー 確認の際に REST クライアントで確認していましたが、データ削除の API を使えたりと SPA として使うとき本来意図していないことが起きてしまうそうです。 この対策のために、リクエストの中に、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
CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん！(Hatena) を読んでの噛み砕きです。 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対策する、みたいな。 まさにイメージがこれだったので。 結論 (結論) ログインのフォームもCSRF対策したほうがいいよ。 被害が出るかはユーザーの気を付け方次第。 被害の大きさはサービスの性質・ユーザーのアウトプットの内容次第。 「閲覧専用」のようなサービスにはほぼ影響が無く、 体感、発生率・被害度は他の攻撃と比べてとても低そうではあるものの、 一律で言ってしまえばCSRF対策を施したほうがよい。 調べたことからの理解 のまえの前置き ログインページ以外のログイン後ページにもCSRF対策をしていないのは問題外
ユーザー：admin パスワード：P@ssw0rd Jenkinsサーバー：http://192.168.1.101:8080 上記の「sample_job」というジョブの情報を「config.xml」というファイル名で保存するには以下のようになります。 以下のようなconfig.xmlが取得できます。 <?xml version='1.1' encoding='UTF-8'?><project> <description>sample job</description> <keepDependencies>false</keepDependencies> <properties/> <scm class="hudson.scm.NullSCM"/> <canRoam>true</canRoam> <disabled>false</disabled> <blockBuildWhenDown
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
今時の CSRF 対策ってなにをすればいいの？ | Basicinc Enjoy Hacking!
【Rails API + SPA】ログイン方法とCSRF対策例 - Qiita
【Rails API】CSRF 対策をあきらめないでちゃんとやる | みどりみちのブログ
SPA + WebAPI でアプリケーションを構築するときの CSRF 対策についてのメモ
SPAでのログイン認証とCSRF対策の実装(JWT使用) - Web備忘録
ID連携におけるCSRF対策のチェック方法 - r-weblife
Spring Securityで簡単にCSRF対策ができる - NRIネットコムBlog
CSRF対策をひよっこエンジニアがまとめてみた(随時更新予定)｜クロノドライブ
SPA + WEB API のCSRF対策とCORSについて - Qiita
RailsとVue.js CSRF対策を意識してシングルページアプリケーションを作ってみる
XSS脆弱性があるとCSRF対策は突破できる | YouTube
Jenkinsに登録されているJob設定のインポート・エクスポート(CSRF対策)
www.webcartop.jp
search.yahoo.co.jp
olafnosuke.hatenablog.com
toaruburogaa.hatenablog.com
ibarakitantei.net
prtimes.jp