通过HTTP头顺序进行浏览器识别
摘要
本文讨论了使用HTTP头顺序、IP选项、用户代理字符串和随机数生成器模式进行被动浏览器识别的技术。
<p><a href="https://lobste.rs/s/4az1lx/browser_identification_through_header">评论</a></p>
查看缓存全文
缓存时间: 2026/06/02 15:50
# 浏览器验证
来源:https://geocar.sdf1.org/browser-verification.html
不信任浏览器的 HTTP User-Agent 字段有非常充分的理由,但大多数技术*看起来*像是浏览器检测代码。本文回顾了一些我所了解的被动方法。
### HTTP 头部顺序
许多浏览器模拟器并不使用与真实浏览器相同的头部顺序。记录这一点很有用。
Firefox 的顺序是:Host, User-Agent, Accept, Accept-Language, Accept-Encoding, Accept-Charset, Keep-Alive, Connection, Referer
Chrome 的顺序是:Host, Connection, Accept, User-Agent, Referer, Accept-Encoding, Accept-Language, Accept-Charset, Keep-Alive
Chrome 以前的顺序是:Host, Connection, User-Agent, Accept, Referrer, ...
MSIE 6 之后的版本顺序是:Accept, Referer, Accept-Language, User-Agent, Accept-Encoding, Host, Connection, Keep-Alive, Accept-Charset
MSIE 6 版本的顺序是:Accept, Referer, User-Agent, Host, Accept-Encoding, Accept-Language, Accept-Charset
MSIE 6 版本有时会是:Accept, Connection, Host, Referer, User-Agent, Accept-Encoding, Accept-Language, Accept-Charset
有时头部会缺失。部分代理服务器会丢弃或插入头部。
### IP 选项
Linux 的顺序是 SACKOK(4) (http://www.ietf.org/rfc/rfc2018.txt), TSTAMP(8) (http://www.ietf.org/rfc/rfc1323.txt), NOP(1) (http://www.ietf.org/rfc/rfc793.txt), WINDOWSCALE(3) (http://www.ietf.org/rfc/rfc1323.txt)。Amazon/EC2 经常使用 WS=7。
OSX 以 TSTAMP(8) (http://www.ietf.org/rfc/rfc1323.txt), SACKOK(4) (http://www.ietf.org/rfc/rfc2018.txt), EOL(0) (http://www.ietf.org/rfc/rfc793.txt) 结尾,并填充一个字节。
Windows 总是将 NOP(1) (http://www.ietf.org/rfc/rfc793.txt) 放在第一位。
某些防火墙会移除 SACKOK、TSTAMP 和 WINDOWSCALE,但它们通常不会重新排列选项列表。收集这些信息很有用,因为浏览器模拟器很少能正确做到这一点。
### User-Agent
建立一个 HTTP User-Agent 字符串及其发布日期的数据库很有用。现代浏览器会自动更新,版本固定并不常见:Google Chrome 很少超过 90 天,超过一半的 Google 用户会在 30 天内升级。Mozilla Firefox 的升级速度较慢,但遵循类似的模式。
### "?_=" + Math.random()
从浏览器记录信息时,经常通过随机数来“破坏缓存”。如果能够按顺序收集五个这样的随机数,就可以可靠地识别旧版本的主流 Web 浏览器。
*直到最近*,Firefox 和 Internet Explorer 都使用相同的简单 LFSR:Firefox 使用 M=53, X=26,旧版 MSIE 使用 M=54, X=27。需要两个连续生成的随机数 d[0,1];找到内部状态的一半来生成第一个随机数:
`` long p=0x5DEECE66DL,a=0xBL,m=(1L<<48)-1,n=(long)(d[0]*(1L<<27))<<(48-X))&m, g=((long)(n&((1L<<27)-1))<<(48-27))&m; ``
然后我们探测所有可能的内部状态,以找到下一个随机数:
`` for (long o=b;o<=(b+((1L<<(48-X))-1));o++) { long t=(o*p+a)&m;if((t&mg)!=g)continue; long r=(t*p+a)&m;t=r; long u=(r>>(48-X))<<27; r=(t*p+a)&m;t=r; long v=(r>>(48-27)); if(d[1]==((u+v)/((double)(1L<<27))))return 1; } return 0; ``
而对于 MSIE(MSIE 6 和 5),则需要进行位反转:
`` unsigned u[5]; for(int x=0;x<5;++x){/* 将每个随机数放入数组 u 中,作为 32 位值 */} unsigned r0=(u[1]>>16)|(((((u[1]>>16)&0xffff)-(18273*((u[0]>>16)&0xffff))&0xffff)<<16)); unsigned r1=(u[0]&0xffff);r1|=(i<<16); for(int j=1;j<5;++j){ r0=(18273*(r0&0xFFFF))+(r0>>16); r1=(36969*(r1&0xFFFF))+(r1>>16); if(u[j]!=((r0<<16)|(r1&0xFFFF)))goto Z; }return 1; Z:0;} ``
现在 Firefox、Safari 和 Chrome 使用 Xorshift128 (https://github.com/v8/v8/blob/085fed0fb5c3b0136827b5d7c190b4bd1c23a23e/src/base/utils/random-number-generator.h#L102),这使得区分变得不可能。
相似文章
通过行为识别:利用UI痕迹对LLM浏览器代理进行指纹识别
本文证明,网站可以通过分析浏览代理的行为模式和时序数据,识别其背后的大语言模型,在14个前沿LLM上实现了高达96%的F1分数。本文正式定义了这一攻击面,并表明随机时序延迟不足以阻止识别。
我的浏览器代理会话中有40%悄然失败,问题不在LLM
一位开发者发现,40%的浏览器代理会话因浏览器指纹识别和自动化检测而悄然失败,而非LLM推理问题。一个名为Leakish的开源工具发现了这些问题。
@hasantoxr: 发现这个后,我再也不愿每月花 500 美元购买反检测浏览器了。它叫 CloakBrowser。一款隐秘的 Chromium……
本文介绍了 CloakBrowser,这是一款基于 Chromium 的开源隐秘浏览器,旨在绕过 reCAPTCHA 和 Cloudflare Turnstile 等机器人检测系统。它声称通过直接修补 C++ 源代码而非注入 JavaScript 来提供卓越的隐秘能力,定位自己为昂贵商业反检测浏览器的免费替代方案。
Agent Browser Shield
Agent Browser Shield 是一款阻止提示注入攻击并降低 AI 浏览器代理 token 成本的产品。
CloakHQ/CloakBrowser
CloakBrowser是一个开源的隐身Chromium浏览器,通过49个C++源码级别的补丁通过机器人检测测试,为Python和JavaScript提供Playwright和Puppeteer的直接替代品。