[讨论]Bing搜索rdr参数

发表于: 2小时前 74

[讨论]Bing搜索rdr参数

梦幻的彼岸

2小时前

最近在使用 Bing 时，注意到一个有趣现象：手动访问搜索页后，浏览器会自动发起一个带 rdr=1&rdrg=... 的二次请求。进一步分析发现，这是 Bing 的 JS 行为监控模块（BM）在检测到缺少 SRCHHPGUSR.HV Cookie 时触发的会话验证机制——尤其在隐私模式下必定触发。

这种“前端 JS 重定向+后端会话绑定”的模式，看似用于反爬和用户验证，但也可能被用于行为追踪、流量染色甚至 A/B 测试注入。

这类“无感验证”机制在现代 Web 应用中越来越常见（如 Google、Cloudflare），大家在攻防实战中是否遇到过类似设计？如何自动化识别或模拟这类行为？

想和大家探讨：

在红队/渗透测试中，如何识别或绕过这类前端触发的隐式请求？

从蓝队视角，能否利用此类行为特征（如 rdr=1 + 特定 Cookie 缺失）作为异常流量检测规则？

这类机制对隐私保护或反自动化工具（如 playwright/selenium）有何影响？是否有通用对抗思路？

一、事件起因

使用2f8K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8W2)9J5k6h3u0A6L8X3N6Q4x3X3g2U0L8$3#2Q4x3V1k6K6k6h3q4J5j5$3S2Q4x3@1k6I4i4K6y4p5i4@1f1#2i4K6R3#2i4@1t1K6i4@1f1&6i4K6V1@1i4@1q4q4i4@1f1#2i4@1q4p5i4K6V1%4i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1^5i4@1u0r3i4K6W2n7i4@1f1^5i4@1p5I4i4K6S2o6i4@1f1$3i4K6V1H3i4K6W2o6i4@1f1%4i4@1t1@1i4@1p5J5i4@1f1#2i4K6S2r3i4K6V1I4i4@1f1%4i4K6S2q4i4@1t1H3g2g2u0x3i4@1f1#2i4K6W2o6i4@1t1H3i4@1f1#2i4K6W2p5i4K6R3H3i4@1f1^5i4K6R3%4i4@1q4m8i4@1f1#2i4K6S2m8i4@1p5^5i4@1f1#2i4@1p5@1i4K6W2m8i4@1f1@1i4@1u0m8i4K6R3$3i4@1f1@1i4@1t1^5i4K6R3H3i4@1f1@1i4@1u0m8i4K6W2n7i4@1f1#2i4K6S2r3i4K6R3J5i4@1f1$3i4K6V1#2i4@1t1H3i4@1f1#2i4K6R3%4i4@1u0m8i4@1f1$3i4K6W2p5i4@1p5#2i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1#2i4@1q4r3i4@1u0o6i4@1f1^5i4K6R3%4i4@1t1@1i4@1f1$3i4K6V1H3i4K6W2o6i4@1f1%4i4@1t1@1i4@1p5J5i4@1f1%4i4@1u0n7i4K6V1K6i4@1f1$3i4K6W2q4i4K6W2o6i4@1f1$3i4K6V1^5i4@1u0q4i4@1f1%4i4@1p5@1i4@1u0m8i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1$3i4K6V1^5i4@1q4r3i4@1f1%4i4K6V1&6i4@1u0q4i4@1f1#2i4@1u0m8i4@1p5$3i4@1f1#2i4K6V1J5i4K6S2o6i4@1f1%4i4K6W2r3i4@1p5#2i4@1f1@1i4@1t1&6i4K6S2q4i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4@1t1^5i4K6V1$3i4@1f1#2i4@1q4p5i4K6V1H3

c18K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8W2)9J5k6h3u0A6L8X3N6Q4x3X3g2U0L8$3#2Q4x3V1k6K6k6h3q4J5j5$3S2Q4x3@1k6I4i4K6y4p5关键字&rdr=1&rdrig=EA02掩码保护CA3D6410A掩码保护

开始还以为是被劫持了，后抓包发现"EA02掩码保护CA3D6410A掩码保护" 关键字是Bing自己响应的

二、事件关键点

（一）影响搜索结果的冠军参数rdr

通过测试对比发现rdr参数影响搜索结果

1.rdr=1时

搜索结果异常

2.rdr=2时

搜索结果正常

三、复现分析详情

（一）复现步骤

Burp 浏览器隐私模式访问等待一段时间就会发现URL多内容了，非该模式要多关闭几次浏览器访问同个URL等待变化（偶然出现）

不同点是：发送请求无cookie

如下图所示：正常请求地址过一段时间后自动请求带有参数的搜索请求覆盖之前的搜索请求内容，表现URL地址栏变化

带参数请求的Referer是手动发送请求的地址

根据该信息过滤发现是该js进行判断的

70fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0L8W2)9J5k6h3u0A6L8X3N6Q4x3X3g2U0L8$3#2Q4x3V1k6J5M7q4)9J5c8U0g2y4k6p5q4H3g2r3M7H3d9q4c8b7x3e0g2*7x3K6g2I4y4g2c8k6e0q4j5^5P5U0c8Q4y4h3k6Y4i4K6u0W2j5Y4u0Q4x3X3g2B7M7H3`.`.

（二）梳理出的判断逻辑

当且仅当以下条件同时满足时，Bing 会通过 JavaScript 自动发起一个带 rdr=1&rdrg=${_G.IG} 的新请求

1. 页面是搜索结果页（URL 中包含 ? 查询参数）

location.href.indexOf("?") > 0

排除首页、静态页等非搜索场景。

2. 当前 URL 中尚未包含 rdr=1（防止无限重定向）

location.href.indexOf("&rdr=1") === -1

3. SRCHHPGUSR Cookie 中缺失“人类验证”标记（HV 或 HVE 字段）

sj_cook.get("SRCHHPGUSR", "HV") 返回空值

备注：

隐私/无痕模式：默认不携带任何 Cookie → 必然触发。

正常模式：

首次访问（无 Cookie）→ 触发。

Cookie 被清除/过期 → 触发。

Bing 主动风控（如检测到自动化行为）→ 临时移除 HV → 触发。

触发后的动作

构造新 URL：

newURL = location.href + "&rdr=1" + (_G.IG ? "&rdrg=" + _G.IG : "");

执行重定向：

location.href = newURL;

实际表现为：页面发起一个新的 GET 请求，但页面内容可能不变（Bing 后端根据 rdr=1 返回“验证通过”的结果）。

写入验证 Cookie：

sj_cook.set("SRCHHPGUSR", "HV", timestamp, false, "/");
sj_cook.set("SRCHHPGUSR", "HVE", _G.Salt, false, "/");

下次访问将不再触发 rdr=1（除非 Cookie 失效）。

场景	是否满足条件 3（无 HV Cookie）	是否触发 `rdr=1`
隐私/无痕模式	✅ 是（无任何 Cookie）	✅ 必定触发
正常模式（首次访问）	✅ 是（无 `SRCHHPGUSR`）	✅ 触发
正常模式（已有 HV Cookie）	❌ 否	❌ 不触发
正常模式（Cookie 被清除/过期/风控）	✅ 是	⚠️ 偶尔触发