如何解决垃圾邮件中的 /@ url？答案

【问题标题】：How is a /@ url found in spam able to be resolved?如何解决垃圾邮件中的 /@ url？
【发布时间】：2016-08-08 01:00:45
【问题描述】：

我最近收到一封包含以下内容的电子邮件（不要点击！）：

<A HrEf="/@/0X0a290d92b/UALI=28389-UI=176738575-OI=279-ONI=5477-SI=0-CI=0-BI=577-II=27913-IDSP=1-KLEM=11-TIE=A-IDE=276135-MID=572-FID=0-DIOM=0" sTyLe=color:#000;font-size:10px;font-family:arial;>
<span>UNS</span></a>

这是原始电子邮件的链接：https://gist.github.com/anonymous/16963a230cab0a3a1bcfc81209f297f1

据我所知，/@ 不是有效的网址。我的浏览器如何将其解析为网站？

【问题讨论】：

@ is allowed in URL paths，所以/@ 是一个有效的相对 URL。
相对于什么？链接在电子邮件中。 https://mail.google.com/@/0X0a290d92b/ 似乎无法解决任何问题。
您使用的是什么浏览器或邮件客户端？也许它针对的是特定的实现。 IE11、Edge 和 Vivaldi 无法打开“/@/0X0a290d92b”
我在 Chromebook 上使用 Gmail。
您可能想要检查由 gmail 创建的实际链接。一个简单的href="http://example.com 将被转发到谷歌并立即重定向。 <a href="https://example.com" style="color:#006699" target="_blank" data-saferedirecturl="https://www.google.com/url?hl=de&q=https://example.com&source=gmail&ust=1111111111111111&usg=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">example.com</a>

标签： email url uri html-email obfuscation

【解决方案1】：

正如 cmets @ is allowed in URL paths 中已经提到的那样。

关于 URL 解析。我猜攻击者使用<base> 标记为电子邮件正文中的所有相关链接显式设置默认 URL，并希望您的浏览器/电子邮件客户端会为您解决。

更新

原来的猜测可能是正确的，因为它是not supported by majority of mail clients

经过一番调查，我意识到0x0A290D92B 实际上是十六进制编码的 IPv4 地址162.144.217.43。我唯一不明白的是它应该如何在浏览器中转换为http(s)://0x0A290D92B。攻击者似乎针对特定的浏览器/邮件客户端行为。

【讨论】：

据此，基本标签在电子邮件中不起作用：stackoverflow.com/questions/14611225/html-base-tag-in-email
@NealFultz 我很感兴趣 :) 你能把你收到的垃圾邮件的原始电子邮件正文放在某个地方吗？
我在问题中添加了指向原始电子邮件的链接。
@NealFultz 谢谢！我已添加有关链接的注意事项，但尚未完成调查
对，@0X0a290d92b/ 解析，但 @/0X0a290d92b/ 没有。 /@/ 似乎永远不会起作用。

【解决方案2】：

它将@ 之前的所有内容都视为传递给 URL 的身份验证信息。 “真实”的 url 在 @ 之后开始，这是 vsminkov 提到的编码 IP 地址。所以前面的正斜杠被丢弃了。

一个更容易阅读的例子：http://username:password@example.com/

这只是一层层的混淆。

这里有一个更详细的有趣链接：

http://www.pc-help.org/obscure.htm

这里是 RFC 2396 描述 URL 的那部分：

涉及直接使用基于 IP 的协议的 URL 方案 Internet 上指定的服务器使用服务器的通用语法 URI 的方案特定数据的组成部分：
 <userinfo>@<host>:<port>
其中可能包含用户名和可选的方案- 有关如何获得访问权限的具体信息服务器。 “@”和“:”部分可以省略。
 server        = [ [ userinfo "@" ] hostport ]
用户信息（如果存在）后跟商业标志 “@”。
 userinfo      = *( unreserved | escaped |
                     ";" | ":" | "&" | "=" | "+" | "$" | "," )

【讨论】：

也许如果它以@ 开头，但/@ 应该是绝对路径，因为它以斜杠开头并且省略了协议。
把@之前的url都解析完后，放入一个请求头域，发送到@之后开始的url。所以得到解析的 url 将是 /0X0a290d92b... 它在尝试解析 URL 之前提取身份验证信息（在这种情况下只是一个反斜杠）。我会尝试找到一个好的参考并在此处发布。
从 RFC 向上述答案添加了更多信息。正斜杠是一个保留字符，所以它在中不应该是有效的。这可能只是导致身份验证数据在某些浏览器上被丢弃（现在或过去）。
还有另一个关于斜杠的问题，/@/，这是否意味着主机是本地主机？当我在浏览器栏中输入/@/ 时，它会将我带到file:///@/
嗯，所以最初的斜杠可能不被视为身份验证的一部分，因为它是保留的，只是删除了 & 符号，使 URL 以 //0x0A290D92B 开头。这似乎可以将用户重定向到恶意网站。