假设是域名欺骗攻击而不是网络钓鱼……这是域名被重定向到虚假站点的地方，而不是域名抢注或诱骗用户访问看起来像目标的完全不同的站点。

这里的区别是至关重要的——从受害者看到的假站点的有效域实际上与真实站点相同，这将导致浏览器将假站点视为相同的 Origin。

这意味着 cookie、本地存储等将可用于虚假站点。

两个缓解点：

• 如果在任何身份验证 cookie 上设置了安全标志，除非通过 HTTPS 访问，否则它们不会被发送到域。
• 如果已经为域设置了HSTS，或者因为用户之前访问过该站点并且在其浏览器中具有该域的 HSTS 条目，或者该站点位于 HSTS 预加载列表中，则用户将无法连接到通过 HTTP 的假站点（如果证书导致浏览器警告，也不是通过 HTTPS）。

如果以上都不适用，并且用户对假站点进行了经过身份验证的会话，那么 cookie 将被发送到假站点，包括任何用于身份验证的站点。希望银行会采取上述任何一种预防措施，但并非总是如此。

是的，攻击者可以向您发送恶意链接，如果您单击它，cookie 信息将传递给攻击者。这种类型的攻击称为跨站点脚本攻击XSS。攻击场景可以有两种类型： 1.存储型 XSS。2.反射型XSS

是的，假设不使用 HTTPS。

在您的情况下，您运行无线网关，并且您有权bankofamerica.com解析到与公共 Internet 上不同的主机。这是一个域名攻击。

Cookie 与域名相关联。当服务器发送Set-Cookie响应标头或脚本用于document.cookie设置 cookie 时，我们说 cookie 是由（或为）该 domain设置的。通常，读取特定域名的 cookie 的能力仅限于具有该域名的服务器。如果名称bankofamerica.com突然指向不同的 IP 地址，这将具有明显的攻击含义。

每次您的浏览器向名为 的服务器发送请求时bankofamerica.com，它都会包含请求中设置的 cookie bankofamerica.com。如果您的计算机要求bankofamerica.com更改时到达的实际服务器（或 IP 地址），您的浏览器并不关心，并将您的bankofamerica.com-set cookie 发送到可接受命名（但实际上是恶意的）服务器。（考虑：有时与域名关联的 IP 地址可以合法更改；您的系统如何知道更改是合法的还是攻击？）

由于您控制了这个流氓服务器，因此您可以看到所有进出的流量。因此，您可以看到客户端浏览器向服务器发送的 cookie 标头。但是，如果您控制路由器，您甚至可以在所有信息到达您的恶意服务器之前（通过路由器本身）看到所有信息，因此除了恶意路由器之外，没有充分的理由实际设置恶意服务器。但是，如果您设法在bankofamerica.com不完全控制路由器的情况下更改了客户端的 DNS 记录，那么您的流氓服务器想法完全符合您的要求。

请注意，HTTPS 可以很好地阻止这种攻击。您的服务器无法成功模拟与 的安全连接bankofamerica.com，因为它没有来自用户信任的证书颁发机构的签名证书。bankofamerica.com除非您可以证明您确实拥有真实的东西（您显然无法证明，因为您不拥有它） ，否则没有证书颁发机构会为您提供签名证书。当您尝试将客户端的安全连接重定向到您的假服务器时，客户端将收到警报，表明可能正在发生攻击。

如果用户第一次尝试http://bankofamerica.com而不是直接访问https://bankofamerica.com，您的邪恶服务器可能会说“无需升级到 HTTPS；让我们只说普通 HTTP”，并且客户端不会收到有关证书的警告。这是SSL 剥离攻击。这可以通过HSTS来防止，服务器可以使用它来告诉客户端，“在接下来的 XX 天/月/年，永远不要通过不安全的连接联系此主机。”

HTTPS 的另一个可能的保护措施是安全 cookie 标志。除非请求通过 HTTPS 进行，否则浏览器不会将安全标记的 cookie 发送到所属域。由于您的服务器无法通过安全连接模拟目标域，因此您将永远无法看到安全 cookie。

是的，他们可以，但取决于浏览器，它甚至根本不需要是网络钓鱼攻击。Internet Explorer 11最近有一个漏洞，允许攻击者窃取 cookie。

许多不同的编程语言可以在网站上运行，并且有些命令可以做一些可怕的事情。如果你在 Linux 上，你可以为 Firefox 设置一个全新的隔离配置文件，这样你的系统就会受到保护。是的，即使是 Linux 也可以被 Java 攻击，并通过远程邪恶女仆攻击来攻击引导加载程序。（为什么我提到邪恶的女仆？因为我只是举一个浏览器漏洞可以走多远的例子。）