モノリス(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によるセッションの管理（ログイン状態の管
安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
ログイン後の利用者のみが利用可能なサービスの悪用 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理 等 ログイン後の利用者のみが編集可能な情報の改ざん、新規登録 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み 等 注意が必要なウェブサイトの特徴 次の技術を利用してセッション管理を実装しているウェブサイトが、CSRF攻撃による影響を受ける可能性があります。 Cookieを用いたセッション管理 Basic認証 SSLクライアント認証 また、上記を実装するウェブサイトのうち、ログイン後に決済処理等の重要な処理を行うサイトは、攻撃による被害が大きくなるため、特に注意が必要です。 届出状況 CSRFの脆弱性に関する届出が、ウェブサイトの届出全体に占める割合は、1パーセント未満と多くはありません。しかしながらこれらの脆弱性については、ソフトウェア製品の届
こんばんは、OAuth👮♂️です。 緊急事態宣言、外出自粛、みなさまどうお過ごしでしょうか？ お家に高い椅子と4KディスプレイとYouTuber並みのマイクを準備し、ようやくOAuth/OIDCを用いたID連携機能の実装に手をつけられるようになった頃かと思います。 本日はID連携時のCSRF対策について、動くものがある状態からのチェックの方法を紹介します。 手元で開発したサービスの登録とかログインにソーシャルログイン機能をつけて「おっ、IdPと繋がった！」ってなったら、Qiitaにその手順を晒すまえにこういうのを試してみましょう。 IdPに遷移する時のURLを確認する ライブラリとかで作る場合は、登録もログインも既存アカウントへの連携も同じような処理が行われるはずです。 なのでだいたいどこでも良いと思います。 ※画像はイメージです ※画像はイメージです Googleでログイン機能とかを
はじめに OAuth2.0の拡張仕様で当たり前になりつつある？PKCEについてまとめました。 「PKCE」とは PKCEとは、「Proof Key for Code Exchange by OAuth Public Clients」の略称で、認可コード横取り攻撃を対策するための、OAuth2.0の拡張仕様です。 みんな大好き？RFCの7636に定義されています。 RFCに読み方も定義されており、「PKCE」も定義されています。 PKCE, pronounced "pixy" とあるので「PKCE」は「ピクシー」と読みます。 ※ ポケ○ンではありません。 認可コード横取り攻撃 この拡張仕様は「認可コード横取り攻撃」の対策を行うための仕様なので、まず、このRFCで対策する攻撃についてまとめます。 この攻撃にはいくつかの前提があります。 OAuth2.0の「認可コード」フローを使用 Public
csrfとは CSRF(クロスサイトリクエストフォージェリ)とは、Webアプリケーションの脆弱性・またそれを利用した悪意のある攻撃を指します。 どんな攻撃か具体例を出してみますね。 仮にhoge.comというサイトにログインしている状態で、下記のリクエストを行うと指定したsend_user_idに指定したpointを送れるとします。 リクエスト先: http://hoge.com/send_point.php メソッド: POST パラメータ: send_user_id ・・・ ポイントを送付するユーザID point ・・・ 送付するポイント数 悪意のある攻撃者が用意したページで下記のフォームがあるとします。 もし、hoge.comにログインしている状態のユーザが下記のボタンを押してしまうと、攻撃者に自分のポイントを送付してしまいます。 もちろん、hoge.comサイトがCSRF対策を行
クロスサイト･スクリプティング（XSS）とクロスサイト･リクエスト･フォージェリ（CSRF）の違い | サイバーセキュリティ情報局
インターネットの普及により、私たちはWebサイト上でさまざまなサービスを受けることが可能になった。その一方で、こうしたWebアプリケーションの脆弱性を狙った攻撃は年々増加している。本記事では、その中でも古典的ながら今なお代表的な脆弱性で、混同されがちなクロスサイト・スクリプティング（XSS）と、クロスサイト・リクエスト・フォージェリ（CSRF）について、改めて仕組みの違いや過去の被害事例、対策を整理し紹介する。 クロスサイト･スクリプティング（XSS）とは 2019年10月24日に独立行政法人情報処理推進機構（IPA）が発表した報告資料によると、2019年第3四半期におけるWebサイト脆弱性に関する届け出件数は278件。そのうち、約58％をクロスサイト・スクリプティング（以下、XSS）が占めている。脆弱性はセキュリティホールとも呼ばれ、アプリケーションのプログラムの不具合や設計ミスによって
概要 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属性をサポート
pysec101 / pysec101 · GitLab
GitLab.com
OAuth で state パラメーターを使わなかった場合に起きうることの例 - dodosuke0920’s blog
Authlete Inc. で事業開発（営業）を担当している 岸田 と言います。前回、イギリスの銀行 API での UX について翻訳してみましたが、今回はもう少し技術よりの話をしたいと思います。 先週、社内の Slack 上で、下記のブログが流れてきました。 medium.com API を公開するサービス自体の脆弱性と、API を利用する側の実装不備を利用した攻撃に関してです。今回の話の中心である state パラメーターについては、その必要性含めいろいろお問合せいただくことも少なくないですし、また、私自身ちょっと理解するのに苦労したので、簡単にまとめてみたいと思います。 報告されている脆弱性 ブログで報告されている脆弱性をまとめるとこんな感じです。 OAuth 2.0 を実装し、API 経由で別サービスにファイルを共有可能なサービスを想定する。そのサービスでは、{{construct
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
CheatSheetSeries/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md at master · OWASP/CheatSheetSeries
Cross-Site Request Forgery Prevention Cheat Sheet Introduction Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site when the user is authenticated. A CSRF attack works because browser requests automatically include all cookies including sessio
タイトル通りです。CSRFトークンはもはや旧ブラウザへの対応が必要である場合を除いて不要です。CSRFトークンを頑張って実装しなくても、CookieのSameSite属性を用いればCSRFは防御可能です。 CSRFの原因 そもそもCSRFはあるオリジンから別のオリジンへCookie付きのPOSTリクエストを行えてしまうことによって起きる問題でした。たとえばCSRFの脆弱性があるbank.example.comという銀行サイトにログインした状態で、下記のコードが含まれる第三者の悪意あるサイトmalicious.example.comを開いて「今すぐクリック！！！」をクリックすると、お金が勝手に送金されてしまいます。 <form action="https://bank.example.com/transfer" method="post"> <input type="hidden" name
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SPA + WebAPI でアプリケーションを構築するときの CSRF 対策についてのメモ
SPAでのログイン認証とCSRF対策の実装(JWT使用) - Web備忘録
ID連携におけるCSRF対策のチェック方法 - r-weblife
OAuth2.0 PKCEとは 〜Stateとの違い〜 - Qiita
サイトを安全に！PHPでcsrf対策を行う方法【初心者向け】
SameSite属性の付与によるCSRF脆弱性対策 - Qiita
CSRFトークンはもはや不要です - Qiita