はてなブックマーク

Chrome Canaryにおいて、新しいセキュリティ機能であるConnection Allowlistsがフラグで有効に出来るようになった。 これは、Webサイトで通信可能なURLの許可リストをHTTPレスポンスヘッダで指定できるようにする。 例 Connection-Allowlistヘッダで通信可能なURLリストを指定する Connection-Allowlist: ("https://asnokaze.com")それ以外のURLのリソースを読み込もうとすると、すべてブロックされます 仕様 Explainerは提案者のGithubで公開されています github.com CSPよりも単純な構文で、外部サイトと通信を制限できるようにします。これによってユーザデータが外部に漏れることを制限します。防御としては万能なわけではなく、著者としても意図的にスコープを絞っていると述べています。 ま

DNSレコードの自動設定をするDomain Connectという仕組みの標準化がIETFで行われています。 未だにDNSレコードを手動設定する機会があります。例えば メール系SaaSでSPF・DMARCレコードを設定する際、マニュアルに沿ってドメイン設定を手動設定したり Webサイトのホスティングサーバなどでカスタムドメインを利用する際に、CNAMEレコードを設定したり SaaSとDNS管理が別サービスであることも多いため、自動設定が出来ないケースもあります。 そこで、Domain Connectはサービスプロバイダー(SaaS)と、DNSプロバイダーが連携し、必要なDNSレコードを自動設定できるようになっています。 すでに幾つかのサービスでは利用できるようになっています サービスプロパイダ: Google Workspace, Shopify など DNSプロパイダ: Cloudflar

今回はWeb AI ファイアウォール Anubis の紹介です。 Anubisは、WebにアクセスしたクライアントにProof-of-Workを課します。単独のアクセスでは大した負荷ではありませんが、分散して大量のアクセスを行うBotに無視できない負荷を与えます。Anubis 曰く、コネクションの魂を評価すると言っています。 動作 具体的な動作としては Webにアクセスすると、Proof-of-Workのページが表示されます。自動で計算処理が始まり、その後、1秒もせず本来のページに遷移します。 Anubisを導入している下記のURLにアクセスすることで体験できます (結果はCookieに保存されるため、2回目は表示されません) https://gitlab.gnome.org/ https://trac.ffmpeg.org/ https://svnweb.freebsd.org/ htt

Protocol Buffersのメディアタイプとして”application/protobuf”などをIANAに登録する動きがある。これにより、Protocol Buffersを返すHTTPレスポンスで指定するContent-Typeヘッダの値が明確になる。 Media Type Registration for Protocol Buffers 現在はIETFに『Media Type Registration for Protocol Buffers』というDraftが提出されているところである。(RFC6838によると、Standards TreeではRFCが必要。) Draftでは下記のメディアタイプの登録している application/protobuf application/protobuf+json また、非推奨としつつも慣習的に使われていた下記もエイリアスとして登録してい

WebにアクセスしてきたAIエージェントやクローラBotが正しいか、確認出来るようにする仕組みがIETFに提案されています。 以下の2つを組み合わせて実現されます。 『HTTP Message Signatures for automated traffic Architecture』 『HTTP Message Signatures Directory』 この仕組みでは、エージェント(AIエージェントやクローラBot)が送信するHTTPリクエストに署名を施します。これにより、Webサイト側は、正規のエージェントであることを確認できるようになります。 背景 IETFのミーティングで、アクセスしてきたAIエージェト・クローラボットを識別するのにIPアドレスやUser-Agentでは不十分という議論がありました。そのときの議論のまとめは以下。 mailarchive.ietf.org 今回、そ

フィッシングやマルウェアのURLを共有する時、リンク化されないように hxxp://example[.]comのように記載する事があると思います。 その変換形式を定義する、『A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators』という提案仕様がIETFに提出されています。 用語 難読化(Obfuscating): 誤ってクリックされないようにする変換のこと 難読化解除(De-obfuscating): 難読化されたものをもとに戻す変換のこと IOC: indicators of compromise。悪意あるURL、メールアドレスのこと もともとは、『無害化(defanging)』『もとに戻す(refanging)』の用語を使ってはいたがObfuscating, De-obfuscatingに

新しくCookieに"__HttpOnly-"プレフィックスを追加する『HttpOnly cookie prefix』という提案仕様が出されています。 前提: Cookie Name Prefixes について Cookieには『Cookie Name Prefixes』という仕様があります(もうそろそろRFCになります)。なお、すでにブラウザに実装されています。 Cookie名にプレフィックスをつけることで、特定の属性が付与されている事が保証されます。 例えばCookie名に "__Secure-" をつけることで、secure属性が付与されている事が保証されます。javascriptや共有先のサイトにより勝手に属性値が外されることはありません。 現在は次の２つのプレフィックスが定義されています __Secure- __Host- googleのサイトもすでに、これらがついたCookie

IETF HTTP WGでCookieを消去するレスポンスヘッダ『Delete-Cookie』の議論が行われています。 正式に提出されたものではありませんが、著者のYoav Weiss氏が個人リポジトリでDraftを公開しています。 yoavweiss.github.io Delete-Cookieレスポンスヘッダの例 Delete-Cookie: foo, fizzcookie nameを羅列することで、それらのcookieを消去するように指示できます。 議論 すでに、Cookieを消すにはいくつかの手段があります。 方法1: expiresを過去の日付を指定することで消去することができますが、domain属性とpath属性を一致させる必要があります。 方法2: Clear-Site-Data ヘッダを使用してcookieを全て消す。 W3Cで定義されているClear-Site-Data

W3CのWeb Application Securityワーキンググループにおいて、Chromeチームから『Local Network Access』というセキュリティ機構の提案がされています。 これは、パブリックなWebページからローカルネットワークへのアクセスを保護するための仕組みです。ただし通信をすべてブロックするのではなく、特定のユースケースにおいては安全に通信を許可する必要があります。 背景 簡単に、パブリックなWebページからプライベートネットワークへの通信に関しておさらいしておきます。 攻撃の例とユースケース パブリックなWebページから、プライベートネットワーク(例 http://192.168.0.1 )へリクエストを送信することができます。 imgタグやフォームでプライベートネットワーク宛にPOSTリクエストを送信する JavaScriptのfetchでGETリクエスト

Webサイトが応答しなくなった場合、ブラウザ側が強制的に停止したり、タブがクラッシュしたりします。 その際の、JavaScriptコールスタックを取得する仕組みとして『Crash Reporting』という仕組みがあります。この仕組みを使うことで、Webサイトを閲覧しているユーザが実際にどこでハングしているのか、コールスタックを調査できるようになります。 具体例 下記のように閲覧したユーザの ハングしたURLが、JavaScriptコールスタック付きのレポートとして取得する事ができます。 (json内改行は見やすくするために修正) Crash Reporting Reporting APIという仕組みがあり、自身のサイトで起こったCSP違反やネットワークエラー(DNSエラー・TLSハンドシェイクエラーなど)を、任意のエンドポイントにレポートさせる仕組みが標準化されています。 NEL(net

『RFC 9669 BPF Instruction Set Architecture (ISA)』として、命令セットアーキテクチャ(ISA)がRFCになりました。eBPF (which is no longer an acronym for anything) と書かれているのが印象的です。 このRFC発行作業は、2023年6月に結成された IETF の bpf WGで行われました。 eBPF Foudationからの相談を元に、Linux Kernelのソースツリーに書かれていたbpf関連ドキュメントを、RFCとして発行していくという形になっています。 (2023年12月 IETF117 bpf WG スライドより) 今後 bpf WGは引き続き活動を続けています。 IETF bpf WGの憲章を読むと、作業スコープとして次のドキュメント発行作業をスコープとしてあげています。 the B

WebページがAIにより学習されないように、拒否できるようにしようという議論があります。 具体的には、ai.txtやrobots.txtなどを使って拒否する提案が出ています。 ai.txt (spawing) https://spawning.ai/ai-txt で 定義されている。 ai.txtの形で配置する 例: User-Agent: * Disallow: *.txt Disallow: *.pdf Disallow: *.doc Disallow: *.docx Disallow: *.odt (略) robots.txt のAI向け拡張 (Microsoft) Microsoftの方らが『Robots Exclusion Protocol Extension to manage AI content use』という提案をIETFに提出している という目的ベースで許可・拒否が出来

.mobi TLDにおいて、WHOISを利用して不正サーバ証明書発行を行う攻撃手法が明らかになり、話題となっている。 この実験者は、実際に 所有してない *.mobi ドメインの証明書発行が出来そうな事を確認している（不正発行の直前で実験を停止）。 簡単に流れを眺めたので、メモとして記録しておく。 詳細 詳細の記事はこちら labs.watchtowr.com 箇条書きで流れを書くと 前提 .mobi TLD の whoisをホストしていたドメインが "whois.dotmobiregistry.net" から "whois.nic.mobi" に移設した "dotmobiregistry.net" を第三者が取得できる状態にあったため取得し、どのような通信が来てるか確認した 大手CAからの通信があり、CAのドメイン所有検証にWHOISのConntactが使える事が判明する 証明書発行手順

2024年7月に、ICANNで .internal トップレベルドメイン(TLD) がプライベート用途として予約されたようです。 背景 長らくプライベート用途で利用できるトップレベルドメインについて議論されてきました。 現在、各組織が独自のTLDをプライベート用に利用しているケースがあります。しかし以下のような問題があります、 新gTLDが登録された際に、衝突する可能性がある Root DNSへ不要な問い合わせがある 実際、.home、.internal、.lan、.corp、.localdomain、.dlink、.zyxel-usg のような問い合わせがRoot DNSに来ていることが知られています。 そこで、.internal をプライベート用途として予約しようというのが、ICANNで議論されている『SAC113：SSAC私的利用TLDに関する勧告（SAC113）』です。 JPNIC

IETFのTLS WGでは、Googleの方らによって提案されている『TLS Trust Anchor Negotiation』という仕組みが議論されています。 これは、クライアントとサーバ側で共に信頼できるCA(トラストアンカー)をネゴシエーションし、複数あるサーバ証明書から適切なものを提供できるようにする仕組みです。 (引用: IETF 120 スライド PDF より) 具体的な提案仕様よりも、explainer を読むのが分かりやすい。自分用に軽く目を通しておく https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md 目次 背景 目標 実現案 Trust Expressions Trust Anchor Identifiers 背景 現状、クライアントがどのCAを信頼しているか伝えず、サーバ側は

TCP(+TLS)上でQUICおよびHTTP/3の通信を行うことを可能にする『QUIC on Streams』という仕様がFastlyのOku Kazuho氏らによって提案されている。 今年3月に行われたのIETF119で提案されている。 仕様は、TCP/TLS上でQUIC通信を行う『QUIC on Streams』と、それを使ってHTTP/3通信を行う『HTTP/3 on Streams』に分かれている。 『QUIC on Streams』 『HTTP/3 on Streams』 今週IETF120があるので、キャッチアップしておく。 モチベーション この提案の背景にあるのは、WebTransportといったHTTP上で動作する新しいプロトコルを設計する際に HTTP/3版とHTTP/2版の両方を設計・メンテナンスを行っているところにあります。 (引用: IETF119スライドPDFより

Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていく はじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス 非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限 その他 今回入らなかった機能 はじめに Cookieの仕様は『RFC 6265: HTTP State Management Mechanism』として標準化されています。 そのCookieの仕様の改訂版が『rfc6265bis』と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"

IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる（例えばIPアドレスが変わってもコネクションを維持できる） HTTPの認証方式をサポートする（Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme） SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス

『Oblivious HTTP』はユーザのプライバシを向上するための技術であり、各ブラウザベンダーおよびCDNベンダーが実装を行っています。 取り組みについては、幾つかの記事があがっています 『Google、Chrome ユーザーのオンラインプライバシー保護を強化するプライバシーサンドボックスのイニシアチブに Fastly Oblivious HTTP リレーを採用』 『Built for privacy: Partnering to deploy Oblivious HTTP and Prio in Firefox』 今回は仕様の観点で、プロトコルの中身に触れていく 背景と目的 通信観点のプライバシーについては、通信の暗号化によりほとんどが保護されています。しかし、幾つか懸念が残っています。 IPアドレスは、短期的に同一ユーザを識別するのに使用できる コネクションは、一連の通信が同一ユー

Apple勢から「Origin-Bound One-Time Codes」というSMSで発行するワンタイムコードのフォーマットの提案仕様がIETFに提出されています。 こちらの仕組みの標準化ということで良いかなと思います。 developer.apple.com 背景 Webのログイン時にSMSでワンタイムコードを送信し、入力させることがあります。昨今ではformの 『autocomplete="one-time-code"』属性によりユーザエージェントがSMSのコードを自動入力してくれたりします。 こちらのサイトでも書かれているように、攻撃者がフィッシングの手口で入力させたID/Passを正規サイトにインプットさせるとSMSコードを自動入力させる事ができます。 akaki.io そこで、SMSで発行したワンタイムコードをドメインに紐付けることでこのような攻撃を防ぐのが今回の目的です Or

IPv4とIPv6デュアルスタック環境において、早く通信確立できた方を使用する『Happy Eyeballs』という仕組みがあります。 「RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency」においては、次のようにAAAAレコードとAレコードの名前解決を行い早く通信確立できたものを使用するようになっています。 今回、そのVersion 3となる『Happy Eyeballs Version 3: Better Connectivity Using Concurrency』という提案仕様が提出されています。著者はAppleやGoogleの方々で、QUIC WGやTLS WGで精力的に活動されている方々です。 Happy Eyeballs Version 3 『Happy Eyeballs Versio

HTTP/2のDDoS攻撃手法として『HTTP/2 Rapid Reset』(CVE-2023-44487)が世間を賑わせています。 各ベンダーから情報が出ています AWS 『How AWS protects customers from DDoS events』 GCP『The attack used a novel technique, HTTP/2 Rapid Reset, based on stream multiplexing』 Cloudflare『HTTP/2 Rapid Reset: deconstructing the record-breaking attack』 このDDoS攻撃はストリームのオープン(HTTPリクエスト)とストリームのキャンセルを繰り返すことで行われます。HTTP/2では、ピアが同時に開くストリーム数を制限する事ができますが、それではオープン/クロー

IETFに『TLS 1.2 is in Feature Freeze』という提案が出されています。 これは、標準化作業上、TLS1.2に新しい機能追加を停止しようという提案です（ただしセキュリティ対応は除く）。TLS1.2やTLS1.3にはエクステンションや、新しい暗号アルゴリズム、Supported Groupsなどを追加できるようになっていますが、それらの追加をTLS1.2では承認しないという話しです。 アプリケーションプロトコルがTLS1.2を利用することを禁止するものではありません。 議論 2023年 3月に行われた IETF 116 TLS WGのミーティングで『TLS 1.2 Deprecation (PDF)』という話しがありました。そこでは、標準化上 TLS 1.2をDeprecation する議論が行われました。 議論は、標準化上の話しと実利用の話しが色々議論されましたが