「Google Chrome」にCookieの盗難を防ぐ技術「DBSC」が導入へ／公開鍵暗号技術やTPMを活用して、セッション盗難の被害を最小限に
html のキャッシュ抑制方法 - poke_dev’s blog
まず一番基本の、html ファイルのヘッダーにメタ情報として指定する方法は、下記。Cache-Control については no-cache もあるけど、no-store の方がキャッシュされない感じ。 <head> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Cache-Control" content="no-store"> <meta http-equiv="Expires" content="0"> </head> ただ、html のキャッシュ抑制対応するには html ヘッダーの meta タグだけでは不十分なようで、キャッシュが表示される場合がある。 その場合 http レスポンスヘッダーにも追加することで、回避出来るみたい (静的 html ファイルも含めて)。 ASP.NET の場合、Web.
ASP.NET IdentityでCookieの有効期間を設定する - blog.beaglesoft.net
こんにちは。beaglesoftの真鍋です。 ASP.NET Identity2でCookieの有効期間を設定する方法ですが、ログイン時にRememberMeチェックボックスのチェックを付けることでログアウトを行わない場合に認証状態を一定期間保持できます。 特に設定を行わない場合には、14日間が有効期間として設定されていますがこの設定を変更することもできます。 具体的には、Startup.AuthクラスのCookieAuthenticationOptionsにExpireTimeSpanを指定します。 public partial class Startup { // 認証設定の詳細については、http://go.microsoft.com/fwlink/?LinkId=301864 を参照してください public void ConfigureAuth(IAppBuilder app)
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: サブドメイ
セキュリティ周りでよく見かける単語についてまとめ（XSS,CSRF,CSP） - Qiita
概要 基本情報技術者のテキストなどでふんわり知ってた単語について改めてまとめました。 誤りなどありましたらご指摘いただけますと幸いです。 クロスサイトスクリプティング（XSS）とは XSSについて 悪意のあるスクリプトをWebページに注入することで、Webページの閲覧者のブラウザ上で悪意のある動作を実行する攻撃のこと。 XSS攻撃は、脆弱性のあるWebアプリケーションにスクリプトを仕込み、そこにアクセスした被害者から情報を盗むことが目的。 XSS攻撃の手順（掲示板サービスの例） 攻撃者は、脆弱性のある掲示板サービスに悪意のあるスクリプトを仕込む。 スクリプトが実行されるよう、攻撃者は、被害者にスクリプトを実行するよう誘導する。 被害者が誘導に従いスクリプトを実行すると、悪意のあるスクリプトが被害者のブラウザ上で実行される。 悪意のあるスクリプトによって、被害者のブラウザからCookie情報
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
Cookie Store API による document.cookie の改善 | blog.jxck.io
Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie 基本的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。 同期 API 最も深刻なのは、 I/O を伴いながら、同期 API として定義されているところだ。 この API は古くから実装されているため、I/O は非同期
セキュリティヘッダ警察です！既に包囲されている！観念してヘッダを挿入しなさい！ - エムスリーテックブログ
【セキュリティチームブログリレー2回目】 こんにちは。エンジニアリンググループの山本です。 セキュリティチームは、エンジニアリンググループ全体のセキュリティを向上させるためのバーチャルチームなのですが、各プロダクト開発チームのサービスをチェックして、協力しながら全体のセキュリティを向上させていくのがミッションです。 そのお仕事の一環として「この部分、セキュリティヘッダが足りないから入れてください！」というやりとりを日常的に行なっています。 今日はこの「セキュリティヘッダ」というものが一体何なのか、今さら人に聞けないアレコレを取りまとめてみたいと思います。 セキュリティヘッダ警察の日常の図(もちろん冗談です) セキュリティヘッダ そもそもセキュリティヘッダとは？ 比較的安全なセキュリティヘッダ X-Content-Type-Options X-XSS-Protection Strict-Tr
セッション管理に関するチートシート - OWASP
Web 認証、セッション管理、およびアクセス制御 Web セッションとは、同一ユーザーに関連付けられた、ネットワーク HTTP リクエストおよびレスポンスの一連のトランザクションのことです。最近の複雑な Web アプリケーションでは、複数のリクエストの間、各ユーザーについての情報や状態を保持することが必要になります。そのため、セッションには、アクセス権やローカライズ設定などの変数を確立できる機能があります。その変数は、セッションが終わるまで、ユーザーと Web アプリケーションとのあらゆる対話に適用されます。 Web アプリケーションは、最初のユーザーリクエストの後に、匿名ユーザーを追跡記録するセッションを作成できます。ユーザーの言語設定の維持が一例です。さらに、Web アプリケーションは、一度ユーザー認証が完了してから、以後のセッションを使用します。これにより、後続のリクエストでユーザー
サードパーティ Cookie をブロックする制限を緩和する CHIPS という仕様について
作成日 2022-12-30 更新日 2022-12-30 author @bokken_ tag Web, Privacy, Security, Cookie はじめに 3rd Party Cookie をブロックする制限を緩和するための仕様である CHIPS が策定されている。¶ 近年、ユーザの Privacy の向上を目的として 3rd Party Cookie をブロックする流れがある。cross site でユーザトラッキングを提供する多くのツールは 3rd Party Cookie を使っているため、3rd Party Cookie をブロックすることで解決しようとするものだ。すでにいくつかのブラウザではこういった動きが見られる(Firefox, Safari)。¶ しかし、一部のサイトでは 3rd Party Cookie が有効に使われているケースもある。こういったケースで
CookieのSameSite属性と4つの勘違い(2022-10版) - セキュアスカイプラス
こんにちは、SSTでWeb脆弱性診断用のツール(スキャンツール)開発をしている坂本(Twitter, GitHub)です。 最近 Fetch API*1 や XMLHttpRequest*2 を使ってクロスサイトのCookieを送る・送らないの実験をする機会がありました。 そこで自分の勘違いが複数発見され、改めて「今のクロスサイト Cookie って難しいな」と感じました。 セキュリティエンジニアのみならず、開発者の方にも参考になるかと思いましたので、自分の勘違いを紹介していきたいと思います。 なお本記事では「サイト」という単語を Cookie における Same-Site の定義に沿って扱います。 Understanding “same-site” and “same-origin” 使用したWebブラウザ: Chrome(burp 同梱のChromium) 106.0.5249.62
CookieのPartitioned属性 (CHIPS) の標準化はじまる - ASnoKaze blog
サードパーティCookieをトラッキングに使用できないようにする「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが議論されています。 現在は、その仕組はW3CのPrivacy CGで議論されています。細かい仕組みは以前書いたとおりです。 ( トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog ) このCHIPSは、Cookieに新しいPartitioned属性を利用します。Cookie自体の仕様は、IETFが発行するRFC 6265で定義されており、そこにPartitioned属性を追加してやる必要があります。 そのためIETF側にも「Cookies Having Independent Partitioned State specif
最近よく見る「Cookie使用同意バナー」、実は無意味？ 専門家が指摘するちぐはぐ対応
Webサイトを見ると、「Cookie（クッキー）」使用への同意を確認するバナーが出てきたことはないでしょうか？ 少し、うざったくも見えるこのバナー。なぜ、最近こうした表示が増えてきたのでしょうか。専門家に聞きました。 Cookie使用の同意を求めるバナーの例（電通公式サイト） そもそも、「Cookie」とは何でしょうか。「Cookie」とは、閲覧したWebサイトのサーバーから発行され、ユーザーのコンピューターなどの中に預けておくファイルのことです。Cookieによって、ユーザーがWebサイトで入力した情報やサイト内のどこを閲覧しているのかといった情報などを、サイトの運営や広告配信業者などが取得することができます。 SNSなどへのログイン状態を維持したり、通販サイトで買い物かごに入れた商品がWebサイトをいったん離れても再表示されたりするのは、Cookieによるものです。一方、企業側もCoo
デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog
Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。 詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。 例 オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。 例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht
Cookieが廃止・規制されたら「別の方法」はある？ ポストCookie時代の対応Q＆A
【ポストCookie時代に活用したい“別の方法”編】 Q1：サードパーティーCookieの代替技術はある？ 前回の記事「【Q&Aで簡単理解】Cookieとは？ 規制で何が変わる？ 広告ターゲティングへの影響は」でもお伝えした通り、サードパーティーCookieがこれまで実現してきたことを単純に代替するような手段は、残念ながら存在していません。さまざまな技術や手法を組み合わせて、ターゲティングや計測などの施策を実現していく必要があります。 サードパーティーCookieが利用できない状況での対応方針は、大きく2つに分けられます。「別の手段を用いて個別にユーザーを識別する」か、「ユーザーを識別しないアプローチをとる」かです。 Q2：ユーザーを識別する手段にはどんなものがある？ ユーザーを個別に識別するための「別の手段」の代表例は、サーバサイドCookieです。サーバサイドCookieは、同一ドメイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Google Chrome」で全体の1％にだけ先行開放中の「トラッキング保護」を試す方法／サードパーティCookieのサポート終了（3PCD）に備えよう【1月24日追記】【やじうまの杜】
IIJ、6月16日施行の「Cookie規制」 を解説〜多くのサイトやアプリが対象になり、情報の公表などが義務に 
sessionとcookieが多分わかる資料