我最近遇到了一种新的网络钓鱼攻击，它使用@符号使 URL 看起来合法。它如下：
我有一个账户totally-legit-site.com，攻击者在他的 IP 上设置了一个钓鱼网站，比如192.168.50.20。然后，他向我发送了一条消息，其中包含一个看起来像的链接。这是为了欺骗用户，让他们认为这是合法网站的链接。http://[email protected]/account
但是，单击此链接会192.168.50.20/account在我的浏览器（Google Chrome）中打开页面。我尝试在@随机域名之前添加带有 的随机内容，而我的浏览器始终能够正确解析页面，并将带有 的内容丢弃@。因此，如果我尝试打开，最终会进入 Google 的主页。http://[email protected]
这真的让我很感兴趣。我找不到有关@域名之前的 URL 的任何信息。这叫什么名字？这是互联网早期的一些过时的东西吗？是否有一些 Web 服务器可以处理 URL 的这一部分（能够修改我的 nginx 实例以根据此参数返回不同的站点会很酷）？
答案1
此语法用于指定协议级身份验证详细信息（用户名，有时还包括密码），以连接到“授权机构”。例如，请参见RFC 3986 第 3.2.1 节。
与 HTTP 一起使用时，凭据将发送在 HTTP授权：标题；格式取决于服务器请求的身份验证机制，但最常见的Basic是使用身份验证而无需进行其他处理。请参阅RFC 7617或者分子动力学。
许多 Web 服务器可以根据“htpasswd”文件、LDAP、SQL 或其他数据库来验证凭证 – 例如对于 Nginx，请参阅auth_basic或 Apache httpdAuthType 基本版。
或者，验证可以由 Web 应用程序自己完成，因为它是通过标准 HTTP 标头和状态代码完成的。例如PHP（但为了使其在 Apache 中工作，您可能需要启用CGIPassAuth或使用奇怪的重写技巧，否则它不会将授权标头转发到应用程序运行时。）
内置 HTTP 身份验证通常用于 API 和其他自动请求，因为它不需要用户交互，不需要存储 cookie 或其他状态，也不需要知道如何格式化“登录”POST 请求（基于 <form> 的身份验证需要它）。
这也与这些提示所使用的身份验证方法完全相同：
相同的语法也适用于 FTP 和许多其他使用 URL 并支持身份验证的协议 - 在所有情况下，都使用该协议的内置机制。
此处的攻击之所以有效，是因为 HTTP 身份验证是可选的，而且在大多数情况下，额外的 HTTP 标头会被 Web 服务器和 Web 应用忽略。反之亦然，浏览器直到服务器要求身份验证时才知道服务器是否会要求身份验证。后已发送请求。
然而，这次袭击并不是新的根本– 它至少从 2000 年代初就出现了。（事实上，在某些时候，浏览器确实开始检查，首先发出请求没有auth 看看服务器是否会回复 401。如果服务器不要求身份验证，Chrome 会在地址栏中隐藏用户名，使真实域名更加明显，而 Firefox 实际上会警告“这可能是在试图欺骗你。”）