Cookieの新しい属性、SameParty属性について - ASnoKaze blog
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
JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
Node.js Security Checklist - RisingStack Engineering
Join 150K+ monthly readers. In-depth articles on Node.js, Microservices, Kubernetes and DevOps. Security – the elephant in the room. Everyone agrees that it is very important but few takes it seriously. We at RisingStack want you to do it right – this is why we have put together this checklist to help you guide through the must have security checks before your application is enabled to thousands o
The Ultimate Guide to handling JWTs on frontend clients (GraphQL)
The Ultimate Guide to handling JWTs on frontend clients (GraphQL) JWTs (JSON Web Token, pronounced 'jot') are becoming a popular way of handling auth. This post aims to demystify what a JWT is, discuss its pros/cons and cover best practices in implementing JWT on the client-side, keeping security in mind. Although, we’ve worked on the examples with a GraphQL clients, but the concepts apply to any
Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備（同ドメイン内なら ...） - Qiita
Auth TokenをlocalStorageに入れようが、cookieに入れようがどっちもXSS危険性には無防備（同ドメイン内なら ...）JavaScriptcookieJWTxsstoken tokenを保存する場所 localStorage cookie cookie (http only) メモリ内 (変数) よく言われるのが JWT tokenをlocalStorageに入れるべきではない ということ。 理由としてはJavascriptで簡単に読めてしまうので、XSSがあった場合意図しないスクリプトを動かされてしまい、結果としてtokenが盗まれるというもの。 対応策として cookie (http only) を色んな所で推奨してる。 https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851 http://cryto.net
"Same-site" and "same-origin" | Articles | web.dev
"Same-site" and "same-origin" Stay organized with collections Save and categorize content based on your preferences. "Same-site" and "same-origin" are frequently cited but often misunderstood terms. For example, they're used in the context of page transitions, fetch() requests, cookies, opening popups, embedded resources, and iframes. This page explains what they are and how they're different from
最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方
2020/02/13 DevSumi 発表資料
Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita
Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
Google Developers Japan: 新しい Cookie 設定 SameSite=None; Secure の準備を始めましょう
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
SameSite cookie recipes | Articles | web.dev
SameSite cookie recipes Stay organized with collections Save and categorize content based on your preferences. Chrome, Firefox, Edge, and others are changing their default behavior in line with the IETF proposal, Incrementally Better Cookies so that: Cookies without a SameSite attribute are treated as SameSite=Lax, meaning the default behavior is to restrict cookies to first party contexts only. C
CSRF is (really) dead
Scott Helme Security researcher, entrepreneur and international speaker who specialises in web technologies. More posts by Scott Helme. A little while back I wrote a blog post about how "CSRF is dead". It focused on SameSite cookies, a powerful yet simple feature to protect your website against CSRF attacks. As powerful as it was, and as much as it will kill CSRF, you had to enable it on your site
SameSite cookies explained | Articles | web.dev
SameSite cookies explained Stay organized with collections Save and categorize content based on your preferences. Every cookie contains a key-value pair along with a number of attributes that control when and where that cookie is used. The introduction of the SameSite attribute (defined in RFC6265bis) lets you declare whether your cookie is restricted to a first-party or same-site context. It's he
Webセキュリティと W3CとIETFの仕様
2. 自己紹介 - ゆき ( @flano_yuki ) - 趣味でW3CとIETFの仕様を読んでブログに書いてる - IETFはオフラインミーティングに数回参加 - たまに脆弱性報告したり (CVE番号発行:1件) - 本業はインフラエンジニア @flano_yuki 3. 今日お話すること - 個人的に気になってる、W3CやIETFで議論されてる仕様を紹介します - 仕様は策定中のものです、大いに変わる可能性があります - 標準化に至らないものや、実装されないものもあるでしょう （紹介しきれないものも沢山あります） 標準化というと敷居が高そうですが、少しでも楽しそうと思って頂ければ幸いです。 興味ある人、詳しい人いましたら、是非お声がけください＞＜； 4. Overview W3C - W3C - Web Apprication Security WG (WebAppSec) - CS
Cookies specification compatibility in modern browsers
Cookies specification compliance issues in modern browsers Star research by Ivan Nikulin (email: ifaaan@gmail.com, github: inikulin, twitter: _inikulin_) This table lists RFC 6265 compliance issues found in modern browsers. Data was obtained by running the IETF test suite across major browsers using a specially made test runner. Test fails are divided into categories for the working group to disti
クッキーインジェクションを試したけど再現できなかった (2) - Qiita
クッキーインジェクションを試したけど再現できなかった 以前、secureクッキーの上書きに成功したことがある、というタレコミをいただいたので、HTTPSで追試してみました。 実験 というわけでHTTPSで実験してみます。適当に証明書をつくっておいてください。 同一URLでのHTTPからHTTPSへの上書きを試みる(secureなし) foo.example.com用のサーバー証明書と秘密鍵を作っておいて、それぞれexample.crt、example.keyという名前でローカルに保存しておきます。実験では間違ってexample.com用のを作ってしまって警告が出た（鍵を作る時のオレオレルートCAはキーチェーンに入れていたのだけどCNを間違った)けど、まあ結果には影響はないでしょう。同じハンドラをhttpとhttpsの両方で使います。httpsでつながれた時（プロトコルがHTTP/2かどうか
クッキーインジェクションを試したけど再現できなかった - Qiita
追試しました クッキーインジェクションを試したけど再現できなかった(2) ももいろテクノロジー「Cookie InjectionによるHTTPSハイジャックについて調べてみる」 クッキーの仕様を逆手に取ったなかなか興味深い攻撃方法があるよと会社の人から先週教えてもらったので試してみたんだけど、再現できなくて、ブラウザですでに対応されたっぽいね、というのを確認したのでメモ。 クッキーインジェクションとは リンク先が詳しいのですが、手短に書くと、HTTPSで保護されたページ用のsecureなクッキーに対して、同一スコープのドメインがあるとHTTPなサブドメインから上書きできちゃったり（Cookie Overwriting）、ドメイン指定の優先度の高いクッキーを使うことでHTTPSなサイトのクッキーを隠す(Cookie Shadowing)可能性があるよ、という問題。HTTPのサイトからHTTP
Cross-Site Request Forgery is dead!
Scott Helme Security researcher, entrepreneur and international speaker who specialises in web technologies. More posts by Scott Helme. After toiling with Cross-Site Request Forgery on the web for, well forever really, we finally have a proper solution. No technical burden on the site owner, no difficult implementation, it's trivially simple to deploy, it's Same-Site Cookies. As old as the Web its
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これからのフロントエンドセキュリティ
The Cookie Monster in Your Browsers
GitHub - hasegawayosuke/vurp: vurp is a vulnerable reverse proxy.
