悪いのは全部 Eve だと思ってた | blog.jxck.io
Intro いつも本ブログを読んで頂いている皆様、そしてセキュリティ関係者の皆様へ。 この度は、筆者による "Eve" に対する不適切な引用、および、原稿内における不名誉な扱いについて、この場を借りて謝罪させていただきます。 Alice と Bob ネットワークやセキュリティ系の解説の中で、プロトコルの送受信を二人の対話構成になぞらえる場合、一方を Alice、もう一方を Bob とする通例があります。 その構成は、業界では長くこの通例が使われており、私的な文書から現場実務まで、あらゆる文書で Alice と Bob は対話を重ねて参りました。 この二人の会話の間で、ひっそりと盗み聞きしている存在が「Eve」です。 C (Charlie), D (Dave) を飛ばしていきなり Eve が登場するのは、盗聴を意味する Eavesdropper に由来していることと、Charlie と Da
Cookie Theft 対策と Device Bound Session Credentials | blog.jxck.io
Intro Chrome チームより提案された Device Bound Session Credentials の実装が進み、Flag 付きで試すことができる。 この提案の背景と、解決する問題、現時点での挙動について解説する。 背景 2FA や Passkey の普及により、認証部分はかなりセキュアになってきた。インシデントによりパスワードが漏洩しても、それだけでなりすましを成立させるのも困難になっている。 そこで攻撃者の注目を集めているのが、Cookie の窃取(Cookie Theft)だ。 認証がいかに堅牢になっても、有効な Session Cookie を盗むことができれば、その値を Cookie フィールドに付与してリクエストするだけで、なりすましを成立させることができる。 いわゆる Session Cookie は、Proof of Authentication として実装さ
Blog: DoubleClickjacking: A New Era of UI Redressing
“Clickjacking” attacks have been around for over a decade, enabling malicious websites to trick users into clicking hidden or disguised buttons they never intended to click . This technique is becoming less practical as modern browsers set all cookies to “SameSite: Lax” by default. Even if an attacker site can frame another website, the framed site would be unauthenticated, because cross-site cook
Chromium policy on JavaScript dialogs | Blog | Chrome for Developers
History of JavaScript dialogs JavaScript was introduced in 1995, and in the very first version of JavaScript were methods on the window object named alert(), confirm(), and prompt(). While they fit into the JavaScript of the time, their synchronous API is problematic for modern browsers. Because the JavaScript engine needs to pause until a user response is obtained, the JavaScript dialogs are app-
Requesting performance isolation with the Origin-Agent-Cluster header | Articles | web.dev
Origin-Agent-Cluster is a new HTTP response header that instructs the browser to prevent synchronous scripting access between same-site cross-origin pages. Browsers may also use Origin-Agent-Cluster as a hint that your origin should get its own, separate resources, such as a dedicated process. Browser compatibility Currently the Origin-Agent-Cluster header is only implemented in Chrome 88 onward.
ブラウザ開発者ツールのネットワークタブに表示されない情報送信手法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻
Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H
なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
Post-Spectre Web Development
Post-Spectre Web Development Editor’s Draft, 19 July 2021 This version: https://w3c.github.io/webappsec-post-spectre-webdev/ Latest published version: https://www.w3.org/TR/post-spectre-webdev/ Previous Versions: https://www.w3.org/TR/2021/WD-post-spectre-webdev-20210316/ Feedback: public-webappsec@w3.org with subject line “[post-spectre-webdev] … message topic …” (archives) Issue Tracking: GitHub
Cookie vs Local Storage マルウェア耐性等に差はあるか？Google Chromeによる保存時の暗号化を検証する - Flatt Security Blog
はじめに こんにちは。セキュリティエンジニアの@okazu_dmです。 皆さんはブラウザにおいてLocal StorageやCookieに格納されている値が暗号化されているかどうかを考えたことはあるでしょうか。これらWebサービスの認証・認可において使われるデータが、XSSのようなアプリケーションの脆弱性への耐性に差があるかどうかは頻繁に議論されるところです。 しかし、ブラウザに保存されたデータが暗号化されているかどうかはまた別の攻撃経路への耐性の話であり、馴染みがないのではないでしょうか。 これは、基礎知識としてLocal StorageとCookieの仕組み/挙動の紹介と比較をしつつ、Google Chromeにおけるそれらの暗号化の実装上の違いを検証する記事です。 なお、保存先のストレージとAuth0のアクセストークンのXSS耐性との関連は過去に別の記事で検証しています。興味がある方
"Same-site" and "same-origin" | Articles | web.dev
"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 each other. Origin The structure of an origin. "Origin" is a combination of a scheme (also known as the protocol, fo
Load cross-origin resources without CORP headers using COEP: credentialless | Blog | Chrome for Developers
We have shipped the new Cross-Origin Embedder Policy (COEP) value credentialless which allows the browser to load cross-origin resources which don't use the Cross-Origin Resource Policy (CORP), by sending a request without credentials, such as cookies. This helps developers to adopt cross-origin isolation more easily. Why we need cross-origin isolation Some web APIs increase the risk of side-chann
Content Security Policy のレポートを収集するためにやったこと - Classi開発者ブログ
はじめに こんにちは、開発本部所属エンジニアの id:kiryuanzu です。 現在、Classi ではサービスのセキュリティリスクをできる限りなくすために Content Security Policy を導入して脆弱性を検知する仕組みの導入を進めています。 本記事ではこの仕組みを導入する上でどのような手順が必要であり、どのような箇所で苦戦するポイントがあったかについて紹介していきます。 筆者は今まで CSP対応に携わったことがなかったのですが、導入段階の時点で想定していたよりも様々な知識が必要なことがわかり、記事にしたいと思いました。 もし数ヶ月前の自分と同じように初めてCSP対応に関わる人の一助となれば幸いです。 Content Security Policy (通称: CSP) って何? Content Security Policy とは、HTTPヘッダの種類の1つであり、クロ
セキュリティの報告先を記述する、security.txtの提案仕様 (RFC9116) - ASnoKaze blog
Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが) 発見者が脆弱性等の報告を出来るような情報を、Web作成者が提供できるようにする仕様がIETFに提出されている。 この「A Method for Web Security Policies」という提案仕様では、security.txtをドメイン直下のURLに配置し、連絡先などを記述するようになっている。 security.txt security.txtは例えば以下のとおりである # Our security address Contact: security@example.com Contact: +1-201-555-0123 Contact: https://example.com/secur
CSPの仕様に report-sample が追加された - ASnoKaze blog
まだ、WIPではあるもののCSPの仕様に "report-sample" と言う機能が追加されました(URL)。 これは、違反したインラインのScriptやStyleの最初の40文字がレポートに追加されます。外部ファイルの場合はレポートされません。昨年から議論がされていましたが、もともとはFirefoxに以前実装されていたscript-sampleプロパティと同等の機能ですが、Styleも対象になります。 これにより、今までレポートは送られてくるもの攻撃なのかそうじゃないのか分からなかったというケースが、多少なりとも少なくなるのではないだろうか。 すでに、Chromeへの実装が進められています(URL) report-sample 普通のCSPと同様に、HTTPヘッダもしくはmetaタグで report-sampleを指定します。 Content-Security-Policy: scri
Sign-in form best practices | Articles | web.dev
If users ever need to log in to your site, then good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-in forms get high bounce rates. Each bounce could mean a lost and disgruntled user—not just a missed sign-in opportunity. Here is an example of a simple sign-in form that demonstrates all of the be
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webセキュリティのあるきかた
CSP: frame-ancestors - HTTP | MDN
Cookie Expires and Max-Age attributes now have upper limit | Blog | Chrome for Developers
Security | Raycast API