Sorry, looks like your network settings are preventing access to this feature. 省流:微软疑似封禁了部分 idc 节点,使用其他更好的代理节点或使用请求头插件伪造来源地址
先说解决方法:
X-Forwarded-For
修改为任意非黑名单 ip(如 1.1.1.1)我怎么知道我节点被封禁了? 直接访问或 curl https://www.bing.com/turing/conversation/create
{"result":{"value":"UnauthorizedRequest","message":"Sorry, you need to login first to access this service."}
或任意内容,说明节点未被封禁测试: 使用 oci(已封禁节点) 直接 get 空白 使用 oci 修改来源为 1.1.1.1 成功 使用 oci 修改来源为另一台 oci ip 失败 使用 gcp 直接 get 成功 使用 gcp 修改来源为 1.1.1.1 成功 使用 gcp 修改来源为 oci ip 失败
分析: 做网站的都知道在有前端 cdn 情况下后端是没法知晓访问者的 ip 的,需要 cdn 给源站传递访客信息。
最传统的方式就是让 cdn 修改 header 中的 X-Forwarded-For 为访客 ip ,后端再执行相应逻辑。
但鲜有人知 header 在结构上更接近一个二元数组,而非字典,也就是说一个 header 的 key(比如 X-Forwarded-For)可以对应多个 value(1.0.0.1,1.0.0.2)
而后端若采用字典方式去获取,只能解得第一个(1.0.0.1)。
正常情况下,访客发出的请求 header 中是不会存在X-Forwarded-For
,所以 bing cdn 采取的加入访客 ip 方式应该是 append(添加,而非修改)。但当我们提前加入一个伪造的 ip ,这将成为第一个,而 cdn 添加的真实 ip 则成为第二个,使得欺骗后端防火墙认为自己的来源是第一个 ip 。换句话说,你只要把来源伪造成任意非黑名单 ip 即可。
此漏洞明显,修复方式简单,故修改 header 的可能不会存留很久。 原文出处
1
marksaas 2023-03-26 18:27:35 +08:00
我没有遇到这个问题,https://t.me/webexplorers 这里有你提的这个解决方案
|
2
Aaron325 2023-03-26 18:42:08 +08:00
不用分析,就是封杀 idc 的 ip 了
找个原生的 ip 基本就没问题 |
3
LouchardBillyham 2023-03-26 19:24:57 +08:00
新注册的 oulook ,切换日本 IP 通过的,现在账号被锁定了
|
4
mmdsun 2023-03-27 12:57:26 +08:00 via iPhone
@LouchardBillyham 那个是列队系统有问题,绕过了排队,现在都是统一排队了吧。
|