Polyfill .ioが中国企業に売却 背景と対応策は？ - ろぼいんブログ
Web開発者たちにとって、ブラウザー間の互換性問題は長年にわたり頭痛の種となっています。そんな中、Polyfill.ioは多くの開発者にとって救世主のような存在でした。 しかし、この度Polyfill.ioは中国企業のFunnullに売却されたことが明らかになり、開発者コミュニティーに波紋を広げています。 この記事では、Polyfill.ioの売却について、またWeb開発者が取るべき対策について詳しく解説します。 Polyfill.ioとは？ 画像：Polyfill.ioの公式サイト Polyfill.ioは、ブラウザー間の互換性問題を解決するためのサービスです。 具体的には、各リクエストのUser-Agentヘッダーを読み取り、リクエストを送信しているブラウザーに適したポリフィルを提供します。 ポリフィルとは、古いブラウザーで新しいブラウザーの機能をエミュレートするためのコードのことです
Brave Browserの脆弱性を見つけた話（iOS編）
Shibuya.XSS techtalk #12の発表資料です。
Origin 解体新書
Web 技術解体新書 第一章 Origin 解体新書 Same Origin Policy とは Web において非常に重要なセキュリティモデルの 1 つだ fetch や XHR でリクエストを送信したときに、 CORS 違反で失敗したり、 Preflight という謎のリクエストが送信されたりして悩んだ経験があるかもしれない。これらは全て、ユーザを保護するために設けられた Same Origin Policy という制限を、ブラウザが遵守した結果なのだ。 本書はこの重要な Origin という概念について、そもそもなぜそんなものが必要なのかという背景や、それがユーザを保護するメカニズム、 JSONP はなぜ危険なのか、 Preflight が飛ぶ理由、 Service Worker など新しい API との連携、 Spectre によって発覚した脆弱性と CORP,COOP,COEP,
Security headers quick reference | Articles | web.dev
This article lists the most important security headers you can use to protect your website. Use it to understand web-based security features, learn how to implement them on your website, and as a reference for when you need a reminder. Security headers recommended for websites that handle sensitive user data: Content Security Policy (CSP) Trusted Types Security headers recommended for all websites
Firefoxは危険なJavaScriptに対応しない - Qiita
Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値
ホスト名の最後が数字なURLの扱いについて - ASnoKaze blog
「WHATWG URL」の仕様で、ブラウザにおいて、ホスト名がIPv4でないが、数値で終わるURLは拒否されるように変更された。 github.com 例えば次のようなものです foo.0 bar.0.09 1.2.3.4.5 今まで、これらのホスト名は、その他のドメインと同じように、通常通り名前解決されます。Issueの起案者は、すでに具体的な攻撃があるわけではないとしつつも、紛らわしさや、eTLD+1 (same-site)の扱いの問題があるとのことです。 なお、次のようなものはIPv4アドレスにマッピングされアクセスできます。 http://127.1 http://1.65793 Deprecate support for URLs with non-IPv4 hostnames ending in numbers 実際に、Chromeでは、そのような変更を入れる検討が始まっていま
GitHub - mikewest/purification
Various web applications often need to work with strings of HTML on the client-side. This might take place, for instance, as part of a client-side templating solution or perhaps come to play through the process of rendering user-generated content. The key problem is that it remains difficult to perform these tasks in a safe way. This is specifically the case because the naive approach of joining s
続・続・国産ブラウザアプリSmoozはあなたの閲覧情報をすべて外部送信している
この記事は過去2回にわたる検証記事の続きとなります。 国産ブラウザアプリSmoozはあなたの閲覧情報をすべて外部送信している 続・国産ブラウザアプリSmoozはあなたの閲覧情報をすべて外部送信している 前回の記事では、おすすめ記事機能を有効にしていると、Smoozがユーザーの閲覧しているURL情報を送信してしまうことについて解説しました。 ユーザーID、URLと共に送信されているbc、bt、bdという項目の内容がわからないままでしたが、これもユーザーの情報であるはずだと思い、調査を続けてきました。 ▼これがおすすめ記事のために送信される内容 （この内容は記事の最後にテキスト情報としても掲載しておきます） URL情報に関連するもので 『c、t、d』 と呼ばれそうなものは何か。 ・cのデータ量は飛び抜けて多い ・cとdは一致が見られることがある ・一部が一致しながらもcのほうが長かったりもする
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
2020年9月よりAppleがSSL証明書の有効期間を13か月に短縮！詳細や対策とは？ | さくらのSSL
今後Safariで起きること Safariとは、Appleで開発されているWebブラウザであり、パソコンであるMacの他にiPhoneやiPad、Apple TV、Apple Watchなどの端末に標準で搭載されています。 このSafariにおいて、2020年9月1日以降に発行された「有効期間が399日以上」のSSLサーバー証明書（以下、SSL証明書）が信頼されないことになります。 具体的なエラー画面の仕様などは明らかにされていませんが、Appleの発表に「This might cause network and app failures and prevent websites from loading.」と書かれていることから、失効したSSL証明書を利用しているサイトにアクセスした時のように、全画面でエラーが表示されてサイトへはアクセスできなくなってしまうことが考えられます。 購入済み
投機的なWebの修復
先日Mozaic.fmでCross Origin Info Leaksについて話しました。 ep63 Cross Origin Info Leaks 雑談編（こちらはプラバシーや新しいEdgeなどセキュリティとは関係ない雑談です） ここではMozaicで話した事をまとめてみたいと思います。 スペクターとはなんだったのか 何が直ったのか 何故ブラウザの問題は残っているのか ブラウザはどの様な対策をとったのか ブラウザの対策は十分だったのか Site Isolationとは Cross-Origin Read Blockingとは Cross-Origin Resource Policyとは Cross-Origin Embedder Policyとは Cross-Origin Opener Policyとは Securer Contextとは スペクターとはなんだったのか スペクターはCPU
Fetch Metadataリクエストヘッダについて (Sec-Fetch-*) - ASnoKaze blog
ブラウザがリソースをFetchするさいに、そのFetchに関するメタ情報をリクエストヘッダに付与するというのがFetch Metadataという仕様です。 この情報を用いれば、画像の読み込みのFetchで銀行用のAPIが叩かれるはずがないといった、明らかな不正なリクエストを検知することができるようになる。 毎度おなじみGoogleのMike West氏によって仕様「Fetch Metadata Request Headers」が書かれている。 以前「Sec-Metadataヘッダについて」で紹介したSec-Metadataをより改良したものです。 ヘッダを分けることでヘッダ圧縮の仕組みとも相性が良くなっています。 Example 以下のような、そのフェッチに関する情報を示すSec-Fetch-*ヘッダが付与される。 Sec-Fetch-Dest: image Sec-Fetch-Mode:
安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
Webデバイストラッキング手法の紹介
サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで / How Snowflake Is Used In CyberAgent - Go To the Future
W3C Workshop for Permissions and User Consentに行ってきた (2) 本編 - そんなことはさておいて
本編です。思ったよりめちゃめちゃ長くなってしまった。2000文字くらいであることが多いのに11000文字とか出てるんですが？？？ 背景 本ワークショップに至る特に重要な背景として、Cambridge Analytica事件とGDPRの施行という2つのできごとがある。これらのできごとによって、Webにおける情報共有とそれへの同意・許諾のあり方への企業やユーザーの見方が大きく変わり、今までのあり方を見直さざるを得なくなった、ということが本ワークショップにつながっていると考えられる。 Cambridge Analytica事件 2018年3月に表面化した、選挙活動へのコンサルティングなどを行うCambridge Analytica社がFacebookユーザーの個人情報を同意なく政治利用していた、という事件。 もともとGlobal Science Research社がthisisyourdigit
Chromium Blog: Trustworthy Chrome Extensions, by default
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
Template:ウェブブラウザにおけるTLS/SSLの対応状況の変化 - Wikipedia
ウェブブラウザにおけるTLS/SSLの対応状況の変化 ウェブブラウザ バージョン プラットフォーム SSLプロトコル TLSプロトコル 証明書のサポート 脆弱性への対応[注 1] プロトコル選択[注 2] SSL 2.0 (安全ではない) SSL 3.0 (安全ではない) TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 EV[注 3][1] SHA-2[2] ECDSA[3] BEAST [注 4] CRIME [注 5] POODLE (SSLv3) [注 6] RC4 [注 7] FREAK [4][5] Logjam Google Chrome (Chrome for Android) [注 8] [注 9]
反則スレスレ !? Super Cookie とは | TECHSCORE BLOG | TECHSCORE BLOG
（Eugene Onischenko / Shutterstock.com） こんにちは、中山です（写真は私ではありません）。 以前の 3rd party Cookie いただきます にて Parasite Cookie の場合、クロスドメインでトラッキングできないことが（業者側の）課題です。 しかし Super Cookie と呼ばれる方法ならばクロスドメインでのトラッキングも可能です。 こちらについては別途ご紹介します。 と結びました。 そこで、今回は Super Cookie と呼ばれる技術についてご紹介したいと思います。 例えばこんな Super Cookie Super Cookie とは、各種擬似 Cookie 技術の総称で、Flash の LSO を利用したシンプルな実装から、ブラウザの閲覧履歴（参考 : css history knocker）や Criteo の ITP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちいさな Web ブラウザを作ってみよう
Security advisory YSA-2018-02
