No243 2022年1月のSafariの脆弱性がよくわからない方へ

今回は、JavaScriptの解説の続きを予定していました。
ですが、その予定を変更し、Safariで見つかった（公開された）脆弱性について解説します。

Safariで見つかった脆弱性というのは、悪意のあるサイトにアクセスすると、その時に開いている他のタブの情報をのきなみ盗み見される可能性があるというものです。

ですが、その報道がわかりにくいと思いますのでその解説をします。

1. どんな脆弱性なのか？

この脆弱性は利用者がSafari（MacintoshやiOSで標準提供されているインターネットブラウザ）で開いている全てのタブの情報を盗み見られてしまうというものです。

インターネットブラウザ(以下、ブラウザと書きます）でサービスにアクセスすれば、そのサービスから情報を取ってきてそれをブラウザの画面上に表示します。
複数のタブを開いていろんなサービスにも同時アクセスしていたとしても、サービス側がそれを知ることはできません。
つまり、いくら悪意のあるプログラムであっても、他のタブで開いているデータを見ることはできないようにしています。
これはプライバシーを守るための大切な仕組みです。

今回の脆弱性ではブラウザではこの仕組みをパスすることができることがわかりました。
悪意のあるサービスが利用者にアクセスしてもらえれば、その時に開いている他の全てのタブの情報に無制限アクセスできてしまうのです。
利用者がどんなサービスをどのように利用しているか？といった情報が盗み取れてしまうというのですから、大変です。
（※何もかもが盗み取れるわけではありません。サービスによりその範囲は異なります）

この脆弱性の影響範囲ですが、少々わかりにくい状況になっています。
MacOS(Macintosh)の場合はSafariを使っている時だけ発生しますので、まぁわかりやすいと言えます。
iOSの場合はSafariだけでなく、どのブラウザでも脆弱性からのがれられません。

特にiOSでは問題を避けることができないわけですから、かなり深刻な脆弱性と言えます。

2. その原因はどこにあるのか？

この原因はハッキリしているのですが、その内容が技術寄りであるため、多くの方にとって「よくわかんないや」といった文にならざるを得ないのです。

以下はImpressのPC watchからの転載です。
「Safari 15などで使われるWebKitに実装された「IndexedDB」APIが「Same-origin policy」に違反した状態になっているというもの。」
(出典 https://pc.watch.impress.co.jp/docs/news/1381056.html)

この説明で「ああ、なるほどね」と理解できる方は今回はこの先読んでも得るものはあまりありません。そういう方は次回をお楽しみに。

というわけで、残っているのは上の説明では「よくわかんない」という方ですよね。
別に、皆さんが悪いわけでも、もちろん上記の執筆者が悪いわけでもありません。

ここに挙がっている「WebKit」「IndexedDB」「Same-origin」といった技術用語がわからなくては理解できるはずがないのです。

というわけで、上記の技術用語を解説していきます。

3. WebKitやIndexedDBもプログラムの名前

さて、一般の方が目にするような多くのソフトは、内部で別のソフトウェア（ライブラリ）をたくさん使っています。
昔から、ソフトウェアというのは全てを自作できない程度に複雑で、必ずといっていいほど別のソフトウェアの助けを借りるものなのです。これは最近に始まったことではなく1980年代の8ビットパソコンの時代からずっとそうです。

Safariというブラウザの場合は、Webkitと呼ばれるライブラリ（プログラム集）を全面的に採用しています。

WebKitには様々なプログラムが含まれていますが、中心となるのは以下の２つです。
1)レンダリングエンジン
　→ブラウザでページ内容を正しくレイアウトする機構
2) JavaScriptのインタプリタ
　→JavaScriptを実行する機構。（詳しくは「No241 JavaScriptってご存知ですか？」をご覧ください）

このWebKitには、サーバから受信したデータの一部をパソコン(PC)に保管するための仕組みが含まれています。各サービスはこの機能をうまく利用して、サーバに情報を取りに行く回数を減らしたりするわけです。（ページキャッシュなどと呼ばれるものとは別の機構です）
このPCに保管する機構というのも結構複雑な仕組みで、それ自体が別のライブラリとして提供されていて、Webkitの場合、IndexedDBという規約を採用しています。

このIndexedDBの仕組みを使えばブラウザの内部にサービス固有の情報が保管できます。
当然ながら機微な情報（病院のサービスであれば病歴、行政サービスなら家族情報、いかがわしいサービスならいかがわしい情報（笑））も含み得るわけです。

こういった情報を関係のないタブから自由に閲覧できてはマズいのです。
仮に悪意がなくても、その情報を表示する広告の選択に使われたりするのは気持ち悪いですよね。ですから、必要ない情報にはアクセスできないように制御するのが正しいのです。

だから、何らかの制限が必要なのですね。

4. Same-origin ポリシーとは？

ブラウザで保管しているサービス固有情報は、ブラウザの管理データの一部です。特に制限をかけなければ、タブを開いているどのサービスからでも全ての情報にアクセスできてしまいます。

ですが、上述のように無関係なサービス情報にアクセスできてしまうのはマズいので何らかの制限をかけなければなりません。

アクセスする時にパスワードなどを照合をする方法などもありますが、インターネットの世界ではよく「Same Origin（セイム=オリジン。同じ組識という意味）」という方式を使います。

サービス固有情報をパソコン内に保管する時の依頼元と同じ（Same Origin)である場合のみ、その情報の参照を許すようにしておくのです。

あるサービス（Ａとします）が service-A.com というドメインでサービスを提供している場合、情報登録時も情報参照時も同じservice-A.comでないと情報を提供しない、という方式です。

こうしておけば、もし、service-B.com がサービスＡのデータにアクセスしようとしても違う依頼元からの依頼だからという理由で情報提供を拒否できます。

この方式はシンプルな割に強固なセキュリティ対策が実現できるので、いろいろな場面で使われています。

ところが、現バージョンのWebKitでは、IndexedDBを利用する際のポリシー定義をミスっており、Same Originでなくてもデータにアクセスできてしまう設定となっています。

そのため、本来ならアクセスできないはずの他のドメインのデータであっても取得できてしまうというのが今回の脆弱性というわけです。

5. 回避方法について

今回の脆弱性は、WebKitでIndexedDBというプログラムの使い方を間違っているのが原因ですから、WebKitを使っているソフトは全てひっかかります。

逆に言えば、WebKitを使っていないブラウザであれば、同じ問題は発生しません。

Macintosh（MacOS）を使っている方であれば、Safari以外（Chrome、Firefoxなど）を使えば回避できます。

問題は、iPhone、iPadなどのiOS上で動いているブラウザです。
Apple社の方針によりiOS上で動作するブラウザはWebKitを使うことと決められているため、AppStoreで配布されている全てのブラウザはWebKitを使っています。
つまり現状で回避方法はない、というのが答えです。

6. 今回の脆弱性の公開について

今回、FingerprintJS という会社がこの脆弱性に気付き、2021年11月28時点でWebKitの開発者向けコミュニティで指摘をしたとのことです。
その後、2022年1月15日になって、自社サイトでこの脆弱性について公開をしました。
「この問題はオープンにして皆で討議すべきだ」ということを主張されています。

ですが、筆者は今回のFingerpringJS社の行動に賛同できません。

一般利用者が回避する方法がない脆弱性では、メーカ（この場合はApple社）に非公開で連絡をし、対処完了（バグ修正版がリリース）後に公開するのが推奨されています。
これは、いわゆるゼロデイ攻撃（バグ修正版のリリース前の攻撃）を避けるためには重要な行動です。

また、バグの修正には時間を要します。
バグの修正自体は数日で完了したとしても、それによって他のバグが発生していないことを確認(テスト)するにも時間が要りますし、他のバグも含めてリリース時期を調整する必要があります。バグの非公式報告から数ヶ月かかることも珍しくありません。

11月にコミュニティで報告してから公開に至った経緯を詳しく知りませんので、間違いがあれば訂正したいと思いますが、現時点で得られている情報から判断する限りは非公開で進めるべき事案であったように感じます。

7. まとめ

2022年1月15日にFingerprintJS社によって、Safariなどのブラウザで同時に開いているタブの情報を取得できてしまうバグがあることが公表されました。

このバグは、Safari内部で使っているWebKitというプログラムの設定ミスが原因でした。その設定ミスはIndexedDBと呼ばれる（さらに別の）内部プログラムの使い方のミスで、Same Originポリシーと呼ばれるルールを無視するような設定となっている点でした。

その設定ミスによって、本来は同じサービス元（Same Origin)が依頼した時だけにデータを参照できるはずが、誰でもデータ参照できるようになってしまったのです。

Macintosh(MacOS)の利用者は当面Safari以外のChromeやFirefoxといったブラウザを使うことで、この脆弱性を回避できるのですが、iPhoneやiPadなどのiOSでは全てのブラウザがWebKitを使うことになっているため、回避方法がありません。

今回のような回避方法がないような脆弱性の場合、公開はしないことが一般的で、公開はバグ修正版がリリースされた後とすることが推奨されています。
筆者は今回のFingerprintJS社の行動には良い印象は持てませんでした。

今回は、2022年1月15日にSafariで発見／公開された脆弱性について解説をしました。

次回はJavaScriptの話に戻ります。
次回もお楽しみに。

（本稿は 2022年1月に作成しました）

このNoteは私が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html