
ブラウザの数学演算がOSごとに異なり、ボット対策システムに検出される
Scrapfly Engineeringが、ブラウザが異なるオペレーティングシステム上で数学関数を異なる方法で実行し、その違いがOSフィンガープリントとして検出されることを文書化した。Chrome 148以降、Math.tanhがホストOSの数学ライブラリを使用し始め、浮動小数点の結果を通じてOS情報が漏洩している。
ブラウザは、各プラットフォームの数学ライブラリに依存することで、検出可能なフィンガープリントを生成している。Linux上のglibcからmacOSのlibsystem_m、Windowsのucrtまで、各OSは微妙に異なる計算結果をもたらす。Scrapfly Engineeringは、ベンダーのlibm内部を逆エンジニアリングすることで、本物のOS数学動作を複製するブラウザを開発した。
Chrome 148での脆弱性
V8 14.8.57では、コミットc1486295ae5がbundled fdlibmをstd::tanhに置き換え、ホストlibmを読み込み始めた。このバージョンはChrome 148で最初に搭載され、以降Chrome 149・150でもOS情報がMath.tanhを通じて漏洩している。一方、Chrome 147以前はこのような数学ライブラリの違いを漏洩しない。
OS間の演算結果の相違
Math.tanh(0.8)の結果はOS間で異なる。Linux上のChrome 150ではMath.tanh(0.8)が0.6640367702678491を返す一方、macOS上では0.6640367702678490、Windows上では0.6640367702678489を返す。この差は最小単位(ULP)で2つに拡がる。さらにMath.tanh(0.7)ではLinuxとmacOSの間に1 ULPの差が生じる。
一方、Math.exp、Math.pow、Math.atanはV8のbundled llvm-libcで計算され、すべてのOS上で同じ結果になる。Math.sinとMath.cosはbundled glibc由来のdbl-64ルーチンを使用しており、やはりすべてのOS上で同じである。
CSSとWebAudio機能での情報漏洩
CSS sin()、cos()、atan2()は、プラットフォームのstd::sinを呼び出し、すべてのOSでOS情報を漏洩させる。またApple Silicon上では、スカラー版libsystem_mとAccelerateフレームワークのベクトル化ルーチンが、関数によって100万入力のうち10~89パーセントの範囲で計算結果が異なる。具体的には、cos(0)はスカラー版libsystem_mで正確に1.0を返すのに対し、Accelerateでは0.9999999999999999を返す。
Web AudioのDynamicsCompressorはサンプル単位の超越関数にスカラー版libsystem_mを使用する一方、FFTおよびベクトル演算にはAccelerateを使用している。これらの違いはスクレイピング検出の強力なシグナルとなる。
検証と対策
Scrapfly Engineeringの検証ハーネスは、リリースごとに871,000個の入力をテストしている。WASMは超越関数オペコードを持たないため、すべてのOS上で数学演算は同じである。
Scrapflyのブラウザは、Math.tanhおよびCSS三角関数において、本物のMacChrome Chrome 150とのbit完全一致を実現している。
筆者の見立て
- 数学演算は防御側にとって強いシグナルであり、スクレイパー側にとっては負債であると論じている
- 数学フィンガープリンティング対策を正しく実装することは、ほとんどのなりすまし対策スタックの想定外にあり、対応が難しいと解釈している
この記事は元記事の事実のみに基づいて自動生成されました。
出典
Scrapfly、「Your Browser Does Math Differently on Every OS, and Anti-Bot Systems Read the Bits」、https://scrapfly.dev/posts/browser-math-os-fingerprint/