一种内容创作上的 "供应链攻击". 在审查的前提下, 大多数第一方只能做到自保, 例外信任(黑名单), 有限信任(白名单). 对于第一方以及黑白名单之外的就只能通过重定向和中间页进行广泛捕获, 再通过分析流量热点来进行第一方审查.
https://twitter.com/Barret_China/status/1697530001921601719
#AdGuard 的 urltransform 修饰符未来有可能会专门应对 "链接重定向中间页" 的情况专门出一个用于 URL decode 的增强选项.
就如这种情况:
真实的第一方链接直接被编码在第三方链接中, 这种类型的中间页一般被用来作出站链接分析.
在 HTML 的环境下有专门针对 标签 href 属性的 href-sanitizer 小脚本, 但脱离浏览器环境之后, 直接通过 HTTP 发送的中间页请求, 这种小脚本就无能为力了. urltransform 允许非同源重定向的很有可能就是为这种复杂情况的让步.
而至于为什么是 "让步", 因为允许过滤器进行非同源重定向的危险程度已经超过了过滤器的 "可信" 等级. 部分社区成员建议将这类过于危险的修饰符特性放进高级设置中.
当前版本下, 对中间页存在的解决办法有两种.
第一种, 直接将被编码的链接通过多步 urltransform 修饰把被编码的字符解码还原出来, 最后再用解码好的第一方链接进行非同源重定向.
第二种, 把第三方的中间页附带核心参数重定向到可信的第一方(第二方?)中间页解析, 避免被不可控制的第三方中间页捕获分析也相当于完成了一部分任务.
对于浏览器的 HTML 环境下, href-sanitizer 当然就能全部解决. 但对于不使用 a 标签的浏览器内跳转(比如 window.location)还是显得无力.
除了简单的 URL encode, 这些中间页还会用 base64url 编码. 有的甚至还会用服务端的 AES 加密第一方链接. base64url 虽然比起 URL encode 复杂, 但起码也算是透明的, 更复杂的保护方式已经超出了编码的范围来到了加密的领域. 根本不是广告拦截器该做的事情了.
uBlock Origin 在 v1.60.0 针对这种情况开始提供了这个 urlskip 修饰符
https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#urlskip
#AdGuard 还没有支持, 状态等级还是 P4.
decode 修饰符的请求已经被 AdGuard 标记为已完成了, 不知道是不是真的已完成. 目前还没有看到文档更新.
Add an option to decode URL in `$urltransform` · Issue #1915 · AdguardTeam/CoreLibs
https://github.com/AdguardTeam/CoreLibs/issues/1915#event-20525027025
Update CoreLibs to 1.20.53 · Issue #5756 · AdguardTeam/AdguardForWindows
https://github.com/AdguardTeam/AdguardForWindows/issues/5756