据我了解，这是攻击者利用点击劫持的方式：
精明的用户要么不会点击链接，要么会注意到地址栏不正确。但是，很多人可能不会注意到。
我的问题是：攻击者不能通过使用malwaresite.com 作为反向代理来达到同样的目的吗？上述所有步骤都是相同的，除了恶意站点.com 会将请求转发到我的站点，然后<script>在 HTML 响应中插入一个额外的标签来运行恶意代码并添加恶意 HTML 元素。在这种X-FRAME-OPTIONS情况下，标头将无济于事，因为没有帧（并且反向代理无论如何都可以将其删除）。
攻击依赖于用户不检查地址栏，所以如果攻击者可以以不同的方式实施相同的攻击并且无法被击败，为什么还要使用X-FRAME-OPTIONS其他点击劫持保护？
这是一个非常有趣的问题。
首先，让我们从您的场景开始：访问网站的用户www.evil.com是加载www.good.com和修改其内容的反向代理。恭喜！您刚刚重新发明了一种经典的中间人攻击，但是非常糟糕。访问evil.com意味着您的浏览器不会发送good.comcookie，这意味着您的反向代理将无法代表用户行事。要解决这个问题，现在您必须欺骗用户使用他的good.com. 恭喜！您重新发明了使用虚假登录页面的攻击。
您描述的场景与点击劫持无关，我们实际上采用点击劫持保护的原因非常不同：通过点击劫持，攻击者会诱骗经过身份验证的用户执行某些操作。即使用户正在访问evil.com，与您建议的使用反向代理的方案不同，他的请求仍会good.com与包含其会话 ID 的 cookie 一起发送。因此，该操作将在经过身份验证的用户的会话中执行。
这听起来很熟悉吗？是的，因为这就是CSRF 攻击的工作方式，但唯一的区别是，对于 CSRF，该操作是以编程方式执行的……除了一件小事：点击劫持会击败反 CSRF 机制。通过点击劫持，该操作由用户自己在用户的浏览器内以及在合法页面（在 iFrame 中加载）内执行。
因此，简而言之：您提出的攻击确实是合理的，但我们使用反点击劫持来击败完全不同的攻击。为此，是的，点击劫持确实是一个真正的、独特的安全问题。
最初的问题是正确地指出，出于网络钓鱼或窃取凭据的目的，点击劫持不会给攻击者带来任何比反向代理或目标站点的简单伪造版本任何显着优势。在每种情况下，浏览器的地址栏都是用户抓住这个诡计的唯一真正方法。
这在对已接受答案的一些评论中得到了澄清，但我认为它应该有自己的专门答案，因为人们正在考虑的与此漏洞相关的大多数风险概况都是未经身份验证的用户通过网络钓鱼泄露其凭据的情况，而不是已通过身份验证或始终未经身份验证的用户被诱骗执行操作的情况。