CSRFとは 悪意の有るWebページを開いた時に、任意のリクエストを対象サーバに送る攻撃方法 リクエストには、ユーザーのブラウザに保存された認証情報が含まれるため、CookieやBASIC認証などの情報が利用される 現在、ほとんどのモダンブラウザでは、Cookieのデフォルトの挙動がsamesite=laxなので他サイトからのPOSTではCookieが送信されない。 そのため、Cookieを利用したPOSTによるCSRFは起きなくなっている。 ただし、以下のケースでは引き続きCSRF対策が必要 利用者のブラウザバージョンが古い場合 利用者がIEやSafari、Firefoxを使っている場合 Cookieを使った認証を行っていない場合 csrf-tokenをRailsのAPIモードで使うには application_controller.rbにinclude ActionController
こんにちは、フロントエンドエキスパートチームの小林（@koba04）です。 フロントエンドエキスパートチームでは、日々の業務としてブラウザやライブラリの更新情報をキャッチアップして社内で共有しています。 例えば先日、CSSのプロパティである image-orientation のデフォルト値が none から from-image に変わったため、画像の Exif 情報の扱いが変更されました。 https://www.fxsitecompat.dev/ja/docs/2020/jpeg-images-are-now-rotated-by-default-according-to-exif-data/ 注： Firefox では COVID-19 の影響により、この変更は延期されました。（Chrome は予定通り 81 で リリースしています） https://blog.chromium.o
実のところ、ウェブサービスのセッションつーものがどうやって実現されているのかをあまり理解してなかった。 特にRuby on Railsではセッションの内容自体をサーバのDBじゃなくてクッキーに保存するということらしいが、その場合のセキュリティ的なこともあまり自信がなかった。 のでちょっと調べてみた。 先にまとめ Railsではセッションの内容がクッキーでやりとりされる（デフォルトの場合） Rails6 ではクッキーが暗号化されているので、クライアント側で改ざんはできない クッキーには httpOnly が指定されているので、サーバに送られるだけでJavaScriptから読み出されることはない Railsでのセッションの使用方法例えばユーザにログインさせる場合に、なんらかの認証をした後にコントローラでセッションにユーザIDをセット： class SessionsController < Ap
RailsのCookieStoreの脆弱性についていくつか報告記事が出ていたので、内容を検討してみました。 Ruby on Railsにcookie保存関連の脆弱性、2000サイトで放置状態 http://www.itmedia.co.jp/enterprise/articles/1311/27/news041.html Rails SessionにCookieStore使った時の問題点 http://oauth.jp/blog/2013/09/26/rails-session-cookie/ 読み合わせていくと、以下のような問題があるようです。 -Cookieの情報が抜かれることによって、セッションをハイジャックされる可能性がある --Rails 2系にはXSS脆弱性からCookieの情報が抜かれる可能性がある --Rails 3/4系でもCookieが盗聴される場合は危険 -セッション
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
サマリ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にて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
はじめに おはようございます､加藤です｡煽り気味なタイトルで申し訳ございません､念の為より詳細に記載しますが､スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です｡ 今後同様の障害への対処として､このブログの対応は行う価値がありますが､これだけやっておけばOKという事では無い事をご理解ください｡ 2019年8月23日にAWSの東京リージョンで障害で特にAmazon EC2とAmazon EBSに､また特定条件下の環境のApplication Load Balancerの一部に障害が発生しました｡ 事象概要を読むと､気になる所がありました｡ 複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS W
https://www.nicovideo.jp // ニコニコ動画 https://live.nicovideo.jp // ニコニコ生放送 https://ch.nicovideo.jp // ニコニコチャンネル 例えば上記のように、異なるサブドメインにおいてもログインセッションなどのデータを共有したい場合があります。 セキュリティの都合上オリジン(<scheme>://<hostname>:<port>)の異なる場所と JavaScript 内でデータの送受信を行う場合はオリジン間リソース共有(CORS)の仕組みを利用する必要があります。 しかし、 CORS のような仕組みを信頼されうるサブドメインの違いだけで利用するのは面倒です。 今回は Cookie の仕様を用いて、データを共有出来るようにします。 要約 ;domain=example.com オプションを付けること。 doma
ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi
1. HTTP クッキーの基本動作HTTP クッキー（以下クッキーと書きます）とは、ウェブサーバー側がクライアント（ウェブブラウザ）側に保持させることができるデータのことをいいます。 クッキーの基本的な動作は以下となります。 (1) ウェブブラウザで サイトA にアクセスする ウェブブラウザで、例えば https://misc.laboradian.com/ にアクセスします。 これは言い換えると、「https://misc.laboradian.com/ というリソースを取得するためのリクエストを misc.laboradian.com というサーバー（ホスト）に送信した」ということになります。 (2) サーバーは、要求されたリソース（ページ）を返す サーバーは、要求されたリソース（ページ）を返しますが、このレスポンスにおけるヘッダ部にクッキー（と呼ばれるデータ）をセットして返すことがで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く