日記スマートフォン用の表示で見るぼちぼち日記おそらくプロトコルネタを書いていることが多いんじゃないかと思います。はじめについ先日のWindowsのセキュリティアップデートでWindowsのCryptoAPIの楕円曲線暗号処理に関連した脆弱性の修正が行われました。Vulnerability」これがまぁ世界の暗号専門家を中心にセキュリティ業界を驚かせ、いろいろ騒がしています。その驚きの一つは、この脆弱性の報告者がNSA(米国家安全保障局)だったことです。NSAはMicrosoftのアナウンスとは別により詳しい内容でこの脆弱性を警告するアナウンスを出しています。Servers」これまで数々の諜報活動をインターネット上で行ってきたNSAが、この脆弱性を自分たちの諜報活動に利用しないというのだろうか?楕円曲線暗号にバックドアを仕込んだのではないかと疑われているNSAが、自ら発見した楕円曲線暗号処理の脆弱性をわざわざ開発元に報告し、修正を求めるなんてことが本当にありうるのだろうか?他にも、NSAは既にもっと巧妙な攻撃方法を使っているのでもうこの脆弱性はいらなくなったとか、他国がこの脆弱性を狙った攻撃を使い始めたからとか、いろんなことを想像しちゃいます。これが本当なら世の中かなり変わったものです。Newsではこの脆弱性の原因について解説をするコメントが寄せられていました。Newsのコメント」これを読んでみると、この脆弱性なかなかヤバそうです。するPoCが作成され、既にいくつか公表されています。POC」の内容は非常に具体的です。私も試してみると本当にHTTPSサーバの証明書を偽造することができました。このデモは、時雨堂さんのサイトを偽造してします。Vさん、ごめんなさい。スクリーンショットにあるよう、IE11のURL表示バーには何もエラーが出ていません。証明書のパスのチェックしてみると、ルート証明書にバッテンがついています。なんか不思議な状態です。通常のユーザはこれが異常であることに気づかないでしょう。Updateで脆弱性修正のパッチをあててみると、まずDefenderがブロックしてサイトにアクセスできません。警告を受け入れてアクセスしてみると、見事URLバーが赤色になり証明書エラーの表示が出ています。これだとひと目で攻撃サイトにアクセスしていることがわかります。Updateしていない皆さん、直ちにパッチをあてましょう。公表したHTTPSサーバを偽造する攻撃手法に限定にして解説したいと思います。コード署名やVPNなどでは他の攻撃ベクターが存在している可能性があります。Algorithm)の処理に関連したものです。ここでECDSAのしっかりした解説をするのはかなり荷が重いです。この記事が分かる程度に超ざっくりとECDSAがどういうものか書いてみます。これでなんとなく雰囲気を掴んでいただければと思います。雑に書いているので、正確に理解したいならちゃんとした本や資料で勉強してください。楕円曲線暗号の特徴は、ECパラーメータという数値セットで決定されます。そのECパラメータには、曲線の係数やベースポイント(G)と呼ばれる計算の開始点、剰余算を行う素数の値、その他いくつかの数値が含まれます。楕円曲線暗号の種類によってその中身も変わります。キモは、ある楕円曲線上の点Gを何倍かして新しい点の位置を計算することはできるが、逆にある点を見てGを何倍してたどり着いた点なのか、その倍数を見つけるのが非常に難しいという性質です。楕円曲線上の点Gを2倍3倍...と進んでいくと、同じ点Gに戻ってくるという性質もあります。ECDSAは、この楕円曲線暗号を使った署名方式です。間で交換しておきます。署名者は、署名作成時に乱数rから生成される点Rとメッセージのハッシュ値(Hash(M))と合わせて署名値SとRのx座標(Rx)を計算し、メッセージと共に署名検証者に渡します。S)とメッセージM、あらかじめ知っているGとPを使って別にRを計算します。この計算したRのX座標が、受け取ったRxと一致していれば署名検証成功です。Pを生成する秘密鍵dを知っている者でないと、この計算を一致させる署名値を作ることができないからです。いった特徴を持つECDSA署名のしくみによってメッセージの認証や完全性が保証され、なりすましや改ざんといった脅威から守ることが可能となります。バグをついてECパラメータを偽造し、署名検証をバイパスできてしまう脆弱性です。P-384などの名前で呼んで識別します(namedCurve)。同じECパラメータでも名付け団体によって名前が異なるのでややこしいし、混乱します。仕様的には名前付けされたパラメータセットではなく、ベタでECパラメータを書いている方式も認められています(specifiedCurve)。CryptoAPIでは、このECパラメータの処理する際にベースポイントGをチェックする処理が見落とされるバグを持っていました。通常署名で利用する公開鍵は、証明書に記載されています。公開鍵を変えてしまうと別の証明書であると見なされます。そこで攻撃者は、ベースポイントGのチェックが甘いCryptoAPIのバグをついて、Gを秘密鍵がわかる位置まで移動させてしまえば、公開鍵Pに対応した秘密鍵を攻撃者が自由に設定できることを見つけました。秘密鍵がわかる位置、そうですG'を公開鍵Pの倍数の位置まで動かせばいいのです。公開鍵Pの座標を変えられないから計算の起点であるベースポイントGを動かす、逆転の発想です。署名検証者が利用するベースポイントGをなんらかの方法で変更することが可能であるならば、公開鍵の値はそのままで攻撃者が自由に秘密鍵の値を決めることができてしまうのです。署名検証者が利用するCryptoAPIではベースポイントのチェックが漏れています。何も知らずに偽造されたベースポイントG'を利用して署名検証をしてしまうと偽造署名の検証が通ってしまうことになります。細かくこれを数式で示したのが以下の図です。自分も実際に紙上で手計算するまでは信じられませんでしたが、お見事です。これ見つけた人はすごい。貴重なコメントを頂きました。頂いたコメントに従い一部表現を修正しました。証明書を使えばいけそうです。ECDSA署名で利用するECC証明書には、namedCurve形式とspecifiedCurve形式の2通りが存在します。仕様的には3つ目のimplictCurve形式も存在しますが、今回は対象外とします。各形式の証明書を実際に見てみましょう。namedCurve形式のECC証明書namedCurve形式の証明書は以下の形です。これがECパラメータを表す名前です。この名前(prime256v1)で規定されているECパラメータの中身は、opensslのコマンドで以下の様に簡単に確認することができます。uncompressedは、ベースポイントの座標がX,Yの座標でエンコードされていることを示しています。namedCurve形式のECC証明書は、opensslのデフォルトでECC証明書の秘密鍵を生成すると使えます。-genkey後述しますが、インターネットのPKIシステムで使われる証明書はこのnamedCurve形式になります。specifiedCurve形式のECC証明書specifiedCurve形式のECC証明書は、ECパラメータを証明書内にベタに書き込む形式です。以下の証明書は、先のnamedCurve形式と全く同じECパラメータ(P-256)の証明書です。名前ではなくECパラーメータの値がベタに記載されています。先程のopensslで出力したECパラメータと全く同じ値が証明書内に明示的に記載されていることがわかるでしょう。今回のCVE-2020-0601は、ここに書かれているベースポイントを偽造した値に入れ替えた証明書を使い攻撃を行います。実証した攻撃手法を試してみます。時雨堂ドメインのサーバ証明書を偽装し、IE11のブラウザーからエラーを出さずに偽のWebサーバにアクセスさせる攻撃です。具体的な攻撃コードは、github.comにのっています。偽造ベースポイントのルート証明書を作るまずは適当な本物のルートECC証明書を探します。NetworkのルートECC証明書を利用しました。このルートECC証明書は、namedCurve形式でP-384を利用していることがわかります。次に攻撃用のルート証明書を作成します。本物のルート証明書から、シリアルと公開鍵データをパクります。次に、P-384のECパラメータを記載したspecifiedCurve形式の証明書から偽造ベースポイントを公開鍵を2倍にした座標に変更します。G'=2Pなので秘密鍵は1/2となります。1/2といっても小数ではなく整数で表します。2倍して1になる数なので、1周して元に戻るちょうど中間折返し地点までの数を示します*1。時雨堂の偽造サーバ証明書を作る時雨堂になりすましを行うHTTPSサーバ用の証明書を作り、この偽造ルートECC証明書を使って署名します。ルート証明書は通常端末の中で管理されており、外部の攻撃者がルート証明書を入れ替えたりすることは容易ではありません。バグ(仕様?)をつきます。CryptoAPIは、署名検証で利用した証明書をキャッシュしているようです。ここからはWindows内部の挙動になるので想定になりますが、どうもシリアル番号・公開鍵・Subjectの情報など証明書の一部の情報が一致していると、ルート証明書といえどもキャッシュ更新を行う感じです。McAfeeから調査ブログが出てました。blogs.mcafee.jpまず最初に攻撃対象となっている本物のルート証明書から発行されたサイトにアクセスしてルート証明書のキャッシュを作成させます。次に攻撃者は、偽造ルート証明書と偽造サーバ証明書をクライアントに送り込みます。通常はルート証明書をサーバからクライアントに送ることはありませんが、しったこっちゃありません。APIでは、なんと偽造ルート証明書にキャッシュを更新します。本来ならECパラメータなど完全に同一のものか厳密にチェックしないといけないのですが、なんとベースポイントのチェックを忘れるバグがありました。楕円曲線の係数とかの情報はちゃんとチェックしているようで完全な見落としだと思います。偽造ルート証明書は、CryptoAPI内では正常なルート証明書として扱われ偽造サーバ証明書の署名検証が成功することになります。これで最初に示した攻撃が完了です。最初に示した攻撃に成功した画面では証明書パスのチェックでルート証明書にバッテンがついていました。これはキャッシュ上のルート証明書で署名検証は成功しているけどクライアントで管理している本当のルート証明書でないのでバッテンをつけているのだと思われます。証明書パスがエラーならURLバーの表示でもエラーを出してもらいたいものです。WindowsはRFC5480違反?実はインターネットのPKIシステムでspecifiedCurve形式の証明書を利用することはRFC違反なんです。PKIX.(implicitCurveとspecifiedCurveはPKIXでは利用しては**いけない**。企業ユーザなどで過去TLS1.0/1.1の古い時代にspecifiedCurve形式を使った証明書を扱うようなケースがあり、互換性を維持するためにこうなってしまったのではないかと思われますが、本当のことはわかりません。specifiedCurve形式のクライアント証明書が使えなくなったというissueがあがってました。Fix扱いでクローズされました。実際にspecifiedCurve形式のサーバ証明書を受け取るとopenssl-1.1.1のクライアントはエラーで接続できないです。いう理由かはわかりませんが、RFC違反で残っていた機能がこんなところで大きな脆弱性として出てきてしまったことは皮肉なもんです。歴史の長いIEだからこそ起きてしまっことなのかも知れません。EDGEでは、ChromiumのネットワークスタックやTLSライブラリ(BoringSSL)を利用しているようなので同じようなことを心配しなくても良くなるでしょう。EDGEでは問題ないように捉えられる記述をしていましたが、間違いでした。(SCT)が入っていないといけないので、SCT必須となる以前の2018年5月1日以前に発行された証明書に偽造する必要があります。サンフランシスコで開催されました。選出していただいたこともあり、CDSに初めて参加しました。Dinosaurフィギュアです。ちなみにゲームはできません。Managerに対して一番最初に投げかけた問いです。PMは直ちに「そんなことはしない」と即答しました。Chromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削除、といったセキュリティに関連するUI変更を立て続けに行ってきています。(繁栄しているウェブの上でユーザを守る)」で話されています。Everywhereが普及し、HTTPS化されたフィッシングサイトも増大している中、今後のChromeブラウザにおけるURL表示に対する考え方は、従来と大きく変わることになりそうです。今回そのセッションの内容について紹介したいと思います。このセッションは、2つに別れています。さんによるChromeのURL表示に関するセッションです。以下は、おおよその講演内容を文字に起こしたものです。サイトのアイデンティティをわかりやすくする。ウェブブラウザの上部に表示されるURLは、ウェブサイトのアイデンティティに対する曖昧な手がかりでしかありません。ドメイン名からサイトのアイデンティティを特定することは、簡単なことではありません。セキュリティ専門家でも見分けがつかないこともあるし、非技術者のユーザとってなおさら無理な話です。このことは憶測に基づくものではなく、多くの実験や調査で示されています。セキュリティに対してちゃんとした決定をしなければならない時に、多くのユーザはURLに気づかなかったり、URLを理解できていないのです。Googleは、1000人以上を対象とした調査を行いました。なっていても、85%の人がそのウェブサイトをGoogleだと言うことがわかりました。これは本当に非常に難しい問題です。多くの人々は、本当に便利なものとしてURLを利用しています。URLが人々を騙したり、害を及ぼすことに使われたりすることもよくあります。そのためGoogleは、いくつかの方向からこの問題にアプローチしています。それは、URLを悪用する巧妙なスプーフィング技術に対して、積極的に対策をします。セキュリティを決定づける最も重要なURL情報に、人々の注意を向けるようにします。専門家をサポートする特別なツールを作っています。それをURLをより良くするセキュリテイツールとして役立たせます。見分けがつかないです。example.comのaがキリル文字だったとしてもわかりません。Warning」という新しい警告を入れるようにしました。これはスプーフされたIDNを検知し、攻撃されていると思われる場合ユーザを正式なサイトに導くページを表示します。Chromeがナビゲーション中のドメインにIDNを見つけると、同じように見える文字種を一つにまとめるアルゴリズムを使い、ドメイン名をスケルトンに変換します。それを有名なサイトや過去にユーザが訪れたサイトのスケルトンと比較します。合致すれば、ユーザを正しいサイトに導くよう、この警告を表示します。Infoに移す変更をしました。これまでの調査・研究結果から、EV証明書が人々にサイトのアイデンティティを理解させるのに役立っていないことがわかったからです。EV表示の終焉」に詳しく書きましたので、そちらを参照してください。大多数の人にとって、wwwサブドメインの表示をしてもしなくても違いはありません。なるし、セキュリティに関連した部分をURLで見つけるのが難しくなります。ユーザに対しては、多くの情報を与えないようにします。UIをより簡単にして、ユーザの注意をURLのセキュリティに関連した部分(ドメイン名)にフォーカスさせます。そのため、これらのURLコンポーネントを隠しました。Omnibox」と呼んでいます。(鍵アイコンの削除など)将来的には、もっとドメイン名に注意を引きつけるUI変更も考えています。OmniboxでURLを編集しようとクリックするまでパスを隠すべきか?ドメイン名を太字にしたり大きく見せて、もっと際立たせるべきか?ユーザーが自分でドメインを検査することになった時に、パスをアニメーション化すべきか?まだどれが良いのかわかっていません。この考えに沿って、最終的にHTTPS接続を示す鍵アイコンも削除する予定です。HTTPS接続を中立な状態として、デフォルトにします。セキュリティがなくなった場合にのみ、警告を出すようにします。インディケータは、かえってユーザを混乱させ、誤ったメッセージを送ることもあります。(これはHTTPSのメンタルモデルを調査した論文を引用し、「鍵アイコンは、自分の認証が必要なことを指していると思っている」というユーザがいたことを指しています。何も出なかったら安全なHTTPS接続である、と思ってもらえるようにしたいです。Chromeは安全でなかったら、警告を出すようにします。調査・準備にもっと時間が必要なので、鍵アイコンをいつ削除するのかは未定です。専門家向けのユーザケース全員がURLを簡略化してほしいと望んでいません。いうChrome拡張です。この拡張を使うとOmniboxのURLが編集されず、常に完全に見えます。デフォルトで有効になっている非技術ユーザを助ける目的のURL簡略化を回避します。サービスに簡単に報告できます。malicious活動をスキャンしているサービスです。Browsingサービスが、報告されたサイトがフィッシングやマルウェア配布・ソーシャルエンジニアリングなど、Googleポリシー違反をしていると判定すれば、全てのChromeユーザに対してそのサイトの訪問をブロックします。Kleberさんによる最近のウェブプライバシー関連の状況とChromeの取り組みについてです。本エントリーの内容から少し外れてしまうので解説は省略しますが、1つ重要なことだけ挙げておきます。クッキーのデフォルト挙動が変わります。cookieは、今のままでは動作しなくなる可能性があります。準備を始めましょう」をよく読んで準備しましょう。まとめ以上セッションの内容から、Googleがスプーフィング対策・非技術者向けにURLの簡略化と効果的なUIの模索・専門家向けにURLを生で見せるChrome拡張の提供、の3つの柱でChromeのセキュリティ対策を進めているのがわかりました。「これは実質的にURLを殺しにきているのではないか?」と言われれば、まぁそうなのかもしれません。URL表示の簡略化は、Omniboxを使うとカーソルが微妙にずれてしまったりして個人的にも違和感があります。慣れの問題かなと半分諦めていました。知って速攻で入れました。ホント快適です(フィッシングサイトの報告はまだしたことないです)。簡略URL表示に違和感のある方は、慣れる前に試してみることをお勧めします。これを使えば、今のところURLが殺されていない世界をGoogleから提供してもらえそうです。HTTPS接続が当たり前となり、フィッシングが巧妙になり、非技術者ユーザが圧倒的多数を占める状況では、URLを確認しろ・証明書を確認しろ・リンクやサイトの記述に注意せよ、といった対応はそろそろ限界に来ているのかなとも思ったりします。HTTPS」で報告されているユーザ調査には、少しショックを受けました。symbol.”「鍵アイコンは、自分の認証が必要なことを指していると思っている。私はよくパスワードを忘れるので、この鍵アイコンを消すためにいつもいろんなところをクリックしてます。2FA.”「HTTPSは悪いプロトコルだ。HTTPSが安全なら私に2FAは必要ないだろう。」まぁこういう状況なら、ChromeのURL表示が簡略化され、セキュリティアクション選択の多くがGoogleのお任せになるのも仕方ないかもしれません。EV証明書の組織名表示がなくなるついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。Infoに「組織名+国名」が表示されるようになります。書いてあることから一気にではなく一部のサイトからEV表示を外すのかもしれません。スクリーンショットです。以前よりGoogleがChromeでEV表示を外すフィールド実験を行っていることは知られていました。今回、Googleはこの大規模なChromeのフィールド実験結果を解析し、EV表示の効果はないということを統計的に示しました。結果、ChromeのURLバーからEV表示を外すという方針を決めました。以下はGoogleのアナウンス文からの引用翻訳です。UIがユーザーを意図したとおりに保護していないと判断しました(Chromiumドキュメントの詳細資料を参照)。UIが変更されたり削除されたりしても、ユーザーはパスワードやクレジットカード情報の入力を避ける、といった安全な選択を行わないようです。UIが提供している防止策に意味があると言えるでしょうか。EVバッジは貴重な画面領域を占有し、派手なUIで紛らわしい会社名を積極的に提示したりします。これは安全な接続に対して有益になるわけではなく、むしろ中立的な表示を目指しているChrome製品の方向性を妨げます。UIを表示する方が良いと考えています。EV証明書の問題ブラウザの表示については、これまで様々な問題提起がされ、大きな議論が行われてきました。詳しくまとまっています。興味のある方はこの資料をぜひ見てください。奥田さんの資料に少し追加しますと、EV証明書の表示に関して少し前に2つ大きなインシデントがありました。証明書を取得しました。ーザを惑わすことが可能であることを実証しました。VerifiedのEV表示2018年AppleはiOS12でSafariでのEVの組織表示をやめました。CABForumのF2F会議の議事録によると、Appleの話では「この変更は、調査と顧客の意見を基に行ったものである。組織名が、ユーザの意図した接続先とドメイン名と同じように結びついているわけではない。Carroll氏が、米国では州が異なれば同じ会社名の法人が設立できることを使い、デラウェア州にある決済のStripe社と同じ社名のStripe社をケンタッキー州で設立しました。この会社を使って正式なEV証明書を取得し、同じStripe社を表示する正当なEV証明書によるフィッシングサイトが立ち上げられられることを公表しました。2つを比べるとURLは異なりますが、EV表示だけを見ていると全く同じです。Protocolの策定を2018年に開始しました。現在の進捗状況は不明です。EV証明書を取得するには、登記簿の提出など組織の実在を証明する厳しい手続きと高い費用が必要です。EV証明書を取得する組織が、法的に問題ない業務を行っているかどうかは認証局チェックの範囲外です。各認証局はEV証明書発行時にフィッシングドメインでないかのチェックを行っています。それは十分ではなく、コスト面さえ折り合えば、このような攻撃がEV証明書を使って行われる可能性があることが示されたわけです。このような問題を持つEV証明書に対して、ブラウザのEV組織表示は本当に必要なのでしょうか?ブラウザのEV組織表示は、本当にユーザのセキュリティに効果があるのでしょうか?10年以上前にIE7やFirefox3を使った数十名を対象とした小規模な調査で、EV表示は有効でないという結果が公表されていました。現在ではブラウザの環境もUIも当時より大きく変わっています。用いて大規模にフィールド実験を行いました。現在のブラウザUIでEV表示が本当にユーザのセキュリティ行動に対して有効なのか判断するためです。公開されている論文から中身を見てみましょう。Chromeのフィールド実験で、Googleは以下の3つの試験を行いました。米国・英国ユーザ(1000名程度)に対するEV表示に関するオンラインサーベイ米国ユーザ(1000名強)に対するURL表示に関するサーベイここでは、1.のChromeのEV表示/非表示のフィールド実験について主に書きます。71)で実施されました。統制群、実験群としてそれぞれ1%のユーザをランダムで割り当て、実験群ではEV表示をしないようにしました。Chromeのユーザ規模になると1%サンプルでも数百万ユーザのデータになっています。Googleは、それぞれのグループに対して以下のメトリックスを取得しました。Infoの表示とその後の操作サイトエンゲージメント取得したデータに対してウェルチt検定を行い、結果は以下の表になりました。統制群(Control)はEV表示しているグループ、実験群(Experiment)はEV表示をしないグループです。Pageの遷移、ファイルダウンロード、Formの送信、Autofillによるクレジットカード情報の送信に関しては、統制群・実験群でその割合に大きな違いは見られませんでした。Infoを表示する」だけです。Infoのポップアップを開けているのです(EVページナビゲーションに対して0.25%対0.02%)。EVページナビゲーションで正規化して解析し直したのが次の結果です。Info後の操作は、EV表示/非表示で大きく変わらないことがわかりました。Infoをよく開けるのでしょうか?論文では以下の2つの仮説が挙げられています。Infoを開けてしまう。Infoを開けている。EV非表示の場合でもセキュリティ行動を変える判断を行うまでに至っていない。結局よく理由はわからないと締めています。20のEVサイトに対するデータの解析も行っています。その結果6サイトで統計的有意差が出ましたが、効果量が少ないため自然変異だろうと結論づけています。Infoを開ける行動には違いがあるものの、EV表示の有無がナビゲーションやページ遷移、ファイルダウンロード、フォーム送信、クレジットカード情報のAutoFillといったユーザのセキュリティ行動に影響しないことが統計的に示されました。これは過去の小規模調査結果と合致しています。他にもGoogleは、1000名を対象としたEV表示のサーベイを実施しています。SafariのEV表示変更でユーザがどのように判断するかサーベイしました。どちらもWebページにログインする際、EV表示がユーザに心理的影響を与えないことがわかりました。ChromeにおけるEV表示の大規模フィールド実験と1000名を対象としたEV表示のサーベイ結果、いずれもEV表示の有効性を示すものではありませんでした。Infoへ移す方針を決めたわけです。URL表示の限界、その先にあるものChromeのURLバーからEV表示がなくなります。ブラウザは、このままのURL表示で大丈夫なのでしょうか?今回の論文では、1000名強のユーザーを対象としてURL表示のバリエーションを変えたサーベイも行っています。アクセスを防止させるような効果はなかったと結論づけています。いうプレゼンを行っています。そこでは、URLは、効果的なセキュリティ・インディケータではない。人々はURLに気づいていない。人々はURLを理解していない。(国際化ドメイン名など)人々がURL(の違い)を理解することが不可能な場合もある。一方で、直ちにURLに替わる画期的で有効な方法といった銀の弾丸は存在せず、まずURL表示を正しくするようにして長期間かけてUIを改善していく必要がある、アイデアやフィードバックが欲しいと訴えています。Googleは、URLに替わる代替案を本当に考えていないのでしょうか?あるChromeのバグチケットにこんなコメントがありました。...)資料がGoogle内部リンクになっているため「実質的にURLを強調させないこと」が具体的に何を指しているのかわかりません。GoogleがURL表示に替わってChromeの表示をどう変えていくのか、今後も注視していきたいと思います。applications」という面白い発表を見つけました。この発表の論文や発表資料、デモ動画などもgithubで公開されていますし、ちょうどタイミングよくセッション動画も最近公開されました。applicationsこの発表で解説されているのは、悪意のある攻撃者が、JavaScript言語固有のプロトタイプチェーンの挙動を利用して、Webサーバを攻撃する方法です。始めとして多くのモジュールにプロトタイプ汚染の脆弱性があることを発見し、報告を行いました。対して、パスワードリセットのリクエストを細工してサーバ上で計算機アプリを実行するデモまで成功しています。JavaScriptの実行環境においてプロトタイプ汚染が発生してしまうことの危険性は、古くから言われていたことですが、これがNode.jsの環境でWebサーバへの攻撃に使われるということは、これまであまり意識されてなかったのではないかと思います。自分の備忘録を兼ねて、ここではその攻撃の仕組みなどを解説してみます。昔から仕様外で裏技っぽく使われてきた機能でした。