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
PSR-7と生PHPに対応したSet-Cookieライブラリを作った - 超PHPerになろう
Cookies default to SameSite=Lax - Chrome Platform Statusということで、何もなければ2020年2月4日にはリリースされる見込みのChrome 80(参考: Chrome Platform Status)を皮切りにCookieにデフォルトがSameSite=Lax相当になるということで、駆け込みでSameSite=Noneを付けて回る需要があるらしいですね。 PHP 7.3が正式リリースされる前に書いたPHPでSame-site cookie - Qiitaが未だに参照されていて厳しい気持ちがあり、さりとて邪悪なPolyfillをまた作ってコピペさせるのも抵抗があり、と悩んでいるうちにバッドノウハウを堂々と書いた記事が出てきてしまったので、仕方なくライブラリにすることにしました。 github.com 週末は具合が悪くて昨晩から衝動的に作
GitHub - bag2php/cookie: Cookie implementation compatible with both PSR-7 and PHP native setcookie()
Re: CookieのPath属性は本当に安全性に寄与しないのか - Qiita
以下の記事を読みました。 CookieのPath属性は本当に安全性に寄与しないのか 結論として以下となっています。 結論。Path属性は特殊な状況下ではある程度安全性に寄与する Path属性は、これを設定してCookieを発行するあるパス(以下「自身のパス」)にサーバサイドのプログラムを書き換えられるような脆弱性がなく、同一オリジン内の別のパスにそのような脆弱性がある場合に、そのパスへのCookieの漏洩することを防ぐことができます。 中略 つまり、「体系的に学ぶ 安全なWebアプリケーションの作り方」の記述はおそらく間違えです。 とはいえ私はセキュリティは専門ではなく、特に攻撃側には疎く、この記事に書いた以上の調査・実験もしていないため、この結論も確実とは言い切れません。詳しい情報をお持ちの方がいたら、ぜひご教示ください。 記事では、iframeなどを用いた攻撃について言及されていて、そ
php7.3より前で CookieのSameSite属性に対応する at softelメモ
問題 2020年2月にアップデートが予定されている「Google Chrome 80」より、CookieのSameSite属性を未設定時の挙動変更がアナウンスされています。 この挙動変更により、WebサイトのCookieの使用方法によっては、外部サイトとの画面連携が正しく行えなくなる可能性があります。 外部サイトからの画面連携する処理フローにて、画面連携時（外部サイトからPOSTメソッドで遷移してくるとき）にログイン状態等の情報が取得できなくなる可能性があります。 セッションCookie発行時に、SameSite=None; Secure を付与しないといけないらしいのですが、どうしたらよいでしょうか。 答え php7.3以降 php7.3からは、setcooike関数、session_set_cookie_params関数で、samesite属性を設定できるようになりました。可能ならばそ
Chrome 80 クッキーのSameSite属性対応のややこしい注意点2つ - こもろぐ @tenkoma
2020年2月4日に Chrome 80 がリリースされました。 このバージョンでは既存のWebアプリケーションの振る舞いに大きな影響を与える変更として、クッキーのSameSite属性の既定値が変わるというのがあります。 ただし、振る舞いの変更は、2月18日以降に予定されています。(正確には「2月17日の週でアメリカ合衆国大統領の日を除く」) Enforcement rollout for Chrome 80 Stable: The SameSite-by-default and SameSite=None-requires-Secure behaviors will begin rolling out to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020,
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
ログイン認証したあとに、WKWebViewでCookieを使ってセッションを保つ方法と失敗例 - Qiita
はじめに ログイン認証が必要なWebViewアプリをWKWebViewを使って作る機会がありました。その際にCookie周りで困ることがあったので、共有のために記事を投稿します。 実現したい仕様 ネイティブで作ったログイン画面に認証情報をいれてログインすると、WebページのTOP画面に遷移 TOP画面以降は認証状態を保ったまま、WebView内で様々な画面に遷移 アプリ側は技術的にはこんな感じでいける?? アプリ起動時に、ネイティブで作ったログイン画面を表示 認証情報をリクエストパラメーターとしてログインAPIを叩く ログインAPIでtokenをアプリ内部に保持(tokenは例えばPHPなら、PHPSESSIDに該当) WebViewを扱うViewControllerに遷移して、WKWebViewをinitしてaddSubView init時に、WKWebViewにtokenをCookie
ガワネイティブのCookie同期 - おぼえがき
はじめまして。 僕は普段アウトプットが足りておらず、リスペクトする先輩から「6月中にブログを作って記事を２本書け」と言っていただき、焦りながらなんとか１本目の記事を書きました。 ツッコミ等ございましたら気軽にコメントしていただけると助かります。 現在、WebViewを多用しているiOSアプリを開発しており、複数のWebView間とネイティブのAPI層でのCookieの同期が必要になってきました。 あるアクションをしたあとに特定のCookieを複数のWebViewとネイティブのAPI層に即時に同期させて更新しなければならず、わりと手こずったのでWebViewのCookie周りについてメモを残します。 ※ 対応しているバージョンは iOS10 / iOS9 です。 ※ iOS11からはこの辺がとてもラクになるらしいです。 複数のWebView間でのCookie同期 同一のWKProcessPo
Web Storage: セッショントークンのマシな手段 ― cookieとセキュリティ面を比較してみる | POSTD
最近、私は「セッショントークンを、cookieの代わりに Web Storage (sessionStorage/localStorage)に保存するのは安全ですか？」ということを尋ねられました。このことについてGoogleで検索したところ、検索結果の上位のほとんどが「Web storageはcookieに比べてかなりセキュリティが弱く、セッショントークンには不向きである」と断言していました。透明性のため、私はこの逆の結論に至った理論的根拠を公に書くことにしました。 Web Storageに関する議論の中核として言われるのは、「Web StorageはsecureフラグやHttpOnlyフラグといったcookie特有の機能をサポートしていないため、攻撃者が容易に盗み取ることが可能」というものです。path属性についても言及されます。私は、これらの機能それぞれについて調べてみました。そして、
JVNVU#92999848: HTTP リクエスト経由で設定された Cookie によって HTTPS 接続がバイパスされたり情報漏えいが発生する問題
JVNVU#92999848 HTTP リクエスト経由で設定された Cookie によって HTTPS 接続がバイパスされたり情報漏えいが発生する問題 RFC 6265 (旧 RFC 2965) は、いわゆる Cookie による HTTP セッションの状態管理の仕組みを規定しています。RFC 6265 を実装しているほとんどのウェブブラウザでは、HTTP リクエストを通じて設定される Cookie によって、HTTPS 接続がバイパスされたり、セッション情報が取得されたりする問題が存在します。 Cookie を用いて HTTP セッションの状態管理を行う場合、様々なセキュリティ上の問題が発生する可能性があることが知られています。 例えば、RFC 6265 の Section 8.6 には次のように記載されています。 Cookies do not provide integrity gua
短時間でcookie解読、RC4暗号通信を破る新手法
HTTPS通信などに使われる暗号アルゴリズムの「RC4」を突破する新たな方法をセキュリティ研究者グループが発表した。 HTTPSなどの暗号化通信に使われている暗号アルゴリズム「RC4」の弱点を突いて、旧来の手法よりも短い時間で暗号化されたユーザーのcookieを解読できてしまう方法が見つかったという。ベルギー・ルーベン大学の2人のセキュリティ研究者Mathy Vanhoef氏とFrank Piessens氏が、「RC4 NOMORE」と題する論文を発表した。 RC4は、30年以上前に開発された古い暗号アルゴリズム。既にWindowsなどではサポートされていないものの、Webサイトの暗号化通信などではサポートが継続され、まだ3割程度の通信で使用されているという。 研究者らによると、この弱点を使った攻撃は、まず悪質なJavaScriptを埋め込んだWebサイトをユーザーに閲覧させ、暗号化された
Origin Cookiesとは - ASnoKaze blog
Origin Cookies GoogleのMike West氏による、Cookieに対する拡張が提案されている。 draft-west-origin-cookies-01では、同一生成元ポリシーと同様なセキュリティポリシーでCookieを扱えるように、Cookie(RFC6265)に"Origin"属性を追加し、HTTPヘッダに"Origin-Cookie"ヘッダを新しく定義する。 "Origin-Cookie"はセットされた時のオリジンと一致するオリジンに対してのみ提出される。 （間違いがあるかもしれません、ご注意下さい） 例 Origin Cookieは、set-cookieヘッダにOrigin属性をつけることでセットされる。 Set-Cookie: SID=31d4d96e407aad42; Secure; HttpOnly; Origin コレを受け取ったユーザエージェントは、H
新型「CookieBomb」マルウェア転送クッションのdecoding方法（日本語版）
*) For the english reader, please use the Google translation to comprehend the context details or you can go straight skimming the screenshots to grasp the idea before translating, this writing is meant to raise awareness of the threat to my fellow countrymen, Japanese friends who got a lot of attack by the covered evil code. *) 追加情報ですが、google,jsの分の細かいdecoding方法が別途内容ですので、アクセスはこちらです。英文ですので、理解が難しいなら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Promiscuous Cookies and Their Impending Death via the SameSite Policy
agilecatcloud.com
プードルも結構だけど、クッキーにセキュア付いてますか？
Implementing cookie consent with “Content Security Policy” – Unsearcher
PHP :: Bug #38104 :: session_start()/session_write_close() creates multiple session cookies headers