发布于 由admin

点击劫持（Clickjacking）的防御机制：X-Frame-Options 与 Frame Busting 脚本

各位同仁，女士们，先生们，

大家好！

今天，我们将深入探讨一个在Web安全领域长期存在且极具威胁的问题——点击劫持（Clickjacking），以及我们如何运用强大的防御机制来对抗它，特别是X-Frame-Options HTTP响应头和客户端的“破框”（Frame Busting）脚本。作为一名在编程领域深耕多年的实践者，我将力求以最严谨的逻辑、最贴近实际的代码示例，为大家揭示这些防御策略的奥秘。

1. 点击劫持：隐形威胁的本质

首先，让我们明确点击劫持究竟是什么。点击劫持，顾名思义，是一种用户界面（UI）欺骗攻击。攻击者通过在用户不可见的透明层中加载一个合法网站，然后诱导用户点击这个透明层上的某个元素。用户以为自己是在与攻击者提供的虚假UI交互，实际上他们的点击行为却被“劫持”并传递给了底层的、合法但不可见的网站。

攻击原理核心：

  1. 加载目标页面： 攻击者创建一个恶意网页，并在其中使用<iframe>、<object>、<embed>等HTML标签，以一个不可见（或部分可见）的方式加载受害者的网站页面。

    <!-- 攻击者页面 (attacker.html) -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>免费领取大奖！</title>
    <style>
        body { margin: 0; overflow: hidden; }
        #overlay {
            position: absolute;
            top: 0; left: 0;
            width: 100%; height: 100%;
            z-index: 10; /* 假装的UI在iframe之上 */
            background: rgba(0, 255, 0, 0.1); /* 只是为了演示，实际是完全透明的 */
            pointer-events: none; /* 允许点击穿透到下面的iframe，这是关键 */
        }
        #victim-frame {
            position: absolute;
            top: -100px; /* 微调iframe位置，使其目标按钮与假装的UI对齐 */
            left: -50px;
            width: 1200px; /* 足够大，覆盖整个屏幕 */
            height: 800px;
            opacity: 0.0001; /* 几乎完全透明，用户看不到 */
            z-index: 1; /* 在假装的UI之下 */
            border: none;
        }
        .fake-button {
            position: absolute;
            top: 200px;
            left: 300px;
            width: 150px;
            height: 50px;
            background-color: blue;
            color: white;
            text-align: center;
            line-height: 50px;
            cursor: pointer;
            z-index: 20; /* 确保假按钮在透明层之上 */
        }
    </style>
</head>
<body>
    <div id="overlay">
        <div class="fake-button">点击这里领取！</div>
    </div>
    <iframe id="victim-frame" src="https://victim.com/transfer_money.html"></iframe>
    <script>
        // 通常，攻击者会动态调整iframe的位置和大小
        // 以精确对齐受害者页面上的敏感操作按钮
        window.onload = function() {
            const victimFrame = document.getElementById('victim-frame');
            // 假设victim.com/transfer_money.html有一个确认转账的按钮，
            // 它的屏幕坐标是 (350, 250) (相对于iframe内部)
            // 攻击者会计算如何调整iframe的top/left，使得这个按钮
            // 恰好位于 fake-button 的正下方。
            // 这是一个简化示例，实际攻击更复杂，可能需要预先了解目标页面的布局。
        };
    </script>
</body>
</html>

    在上述示例中，#victim-frame被设置为几乎完全透明，并且通过top和left属性进行偏移，使得其内部的某个关键操作按钮（例如“确认转账”）恰好与攻击者页面上的“点击这里领取！”这个诱导性按钮重叠。pointer-events: none;属性允许用户点击#overlay时，点击事件能够“穿透”到下面的<iframe>。

  2. 诱导用户点击： 攻击者通过各种社会工程学手段（如虚假广告、钓鱼邮件等）诱导用户访问这个恶意页面。

  3. 劫持点击事件： 当用户在恶意页面上点击了攻击者预设的诱导性元素时，由于底层的合法页面是不可见的，用户并不知道自己的点击行为实际上是发送给了合法页面。例如，用户可能以为自己在点击一个“播放视频”按钮，实际上却点击了合法网站的“删除账户”按钮。

潜在危害：

  • 会话劫持： 用户在合法网站上已登录，攻击者利用用户会话进行操作。
  • 非授权操作： 修改用户设置、发布内容、进行转账、删除账户等敏感操作。
  • 信息泄露： 即使是点击选择文件等操作，也可能被劫持。
  • 绕过CSRF防护： 许多CSRF防护机制依赖于用户提交的表单中包含的Token。但点击劫持并不涉及表单提交，而是直接利用用户已登录的会话，通过点击触发页面上的JavaScript事件或链接。

点击劫持的危险之处在于其隐蔽性高，用户难以察觉。它并不需要攻破服务器，也不需要窃取用户凭证，仅仅利用了浏览器对<iframe>等标签的渲染特性以及用户对UI的信任。

2. 防御机制一：X-Frame-Options HTTP 响应头

X-Frame-Options 是一个HTTP响应头，它允许网站管理员声明其页面是否可以在 <frame>、<iframe>、<embed> 或 <object> 中被加载。这个头部是一个简单而有效的服务器端防御机制，由微软在IE8中率先引入，随后被各大浏览器广泛支持。

2.1 语法与指令

X-Frame-Options 响应头有三个主要指令：

  1. DENY:

    • 含义： 明确禁止任何网站将当前页面嵌入到 <iframe>、<frame>、<embed> 或 <object> 中，无论嵌入页面的来源是什么。
    • 安全性： 最安全的选项，推荐用于所有不希望被嵌入的页面。
    • 示例： X-Frame-Options: DENY

  2. SAMEORIGIN:

    • 含义： 允许当前页面被同一个源（Same Origin）的页面嵌入。这意味着只有当父框架的URL与当前页面的URL具有相同的协议、主机和端口时，才允许嵌入。
    • 安全性： 适用于需要内部嵌套的场景，例如，一个应用的子页面需要嵌入到主页面中。
    • 示例： X-Frame-Options: SAMEORIGIN

  3. ALLOW-FROM uri:

    • 含义： 允许指定的 uri 将当前页面嵌入。这个指令允许白名单机制。
    • 安全性： 相对于 DENY 和 SAMEORIGIN，这个指令的安全性较低，因为它依赖于一个明确的白名单，如果白名单配置不当，可能会引入风险。此外，它在现代浏览器中的支持情况不佳，已被废弃或不推荐使用。
    • 示例： X-Frame-Options: ALLOW-FROM https://trusted.example.com/

2.2 实现方式

X-Frame-Options 是一个HTTP响应头，因此需要在服务器端进行配置。以下是在不同Web服务器和应用框架中设置此头部的常见方法。

2.2.1 Apache HTTP Server

在Apache的配置文件（例如 httpd.conf 或虚拟主机配置文件）中，可以使用 mod_headers 模块来添加 X-Frame-Options 头。

# 启用mod_headers模块，如果尚未启用
# LoadModule headers_module modules/mod_headers.so

<IfModule mod_headers.c>
    # 禁止任何网站嵌入此页面
    Header always set X-Frame-Options "DENY"

    # 或者，只允许同源嵌入
    # Header always set X-Frame-Options "SAMEORIGIN"

    # 注意：ALLOW-FROM 已不推荐，且支持有限
    # Header always set X-Frame-Options "ALLOW-FROM https://trusted.example.com/"
</IfModule>

Header always set 会确保在所有响应中都添加此头，即使是错误响应。

2.2.2 Nginx

在Nginx的配置文件（例如 nginx.conf 或站点配置文件）中，可以在 http、server 或 location 块中添加 X-Frame-Options 头。

server {
    listen 80;
    server_name example.com;

    # 禁止任何网站嵌入此页面
    add_header X-Frame-Options "DENY";

    # 或者，只允许同源嵌入
    # add_header X-Frame-Options "SAMEORIGIN";

    location / {
        # ...
    }
}

add_header 指令会在每次响应时添加指定的HTTP头。

2.2.3 Node.js (Express 框架)

在Node.js中使用Express框架时，可以通过 helmet 中间件或手动设置响应头。helmet 是一个安全中间件集合，强烈推荐使用。

使用 Helmet (推荐):

const express = require('express');
const helmet = require('helmet');
const app = express();

// 使用 helmet.frameguard 中间件
// 默认是 DENY
app.use(helmet.frameguard({ action: 'deny' }));

// 或者设置为 SAMEORIGIN
// app.use(helmet.frameguard({ action: 'sameorigin' }));

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

手动设置响应头:

const express = require('express');
const app = express();

app.use((req, res, next) => {
  // 禁止任何网站嵌入此页面
  res.setHeader('X-Frame-Options', 'DENY');
  // 或者只允许同源嵌入
  // res.setHeader('X-Frame-Options', 'SAMEORIGIN');
  next();
});

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

2.2.4 Java (Spring Security 框架)

在Java的Spring Security框架中，可以通过配置来启用 X-Frame-Options 防御。

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            // ... 其他安全配置 ...
            .headers()
                .frameOptions()
                    .deny(); // 设置 X-Frame-Options: DENY
                    // 或者 .sameOrigin(); // 设置 X-Frame-Options: SAMEORIGIN
    }
}

2.2.5 PHP

在PHP应用中，可以直接使用 header() 函数来设置 X-Frame-Options 头。

<?php
// 禁止任何网站嵌入此页面
header('X-Frame-Options: DENY');

// 或者只允许同源嵌入
// header('X-Frame-Options: SAMEORIGIN');

// ... 你的页面内容 ...
echo '<h1>欢迎来到我的安全网站！</h1>';
?>

请确保 header() 函数在任何输出发送到浏览器之前调用。

2.3 浏览器支持与局限性

浏览器支持： X-Frame-Options 在所有现代浏览器（包括Chrome、Firefox、Safari、Edge、IE8+等）中都得到了良好支持。这使得它成为一种非常可靠的防御机制。

局限性：

  • 单一维度： X-Frame-Options 专门用于控制页面是否可以被嵌入。它无法防御其他形式的UI重绘攻击（如CSS覆盖、拖放劫持等），这些攻击可能不依赖于 <iframe>。
  • 优先级： 当页面同时设置了 X-Frame-Options 和 Content-Security-Policy 的 frame-ancestors 指令时，现代浏览器会优先遵守 frame-ancestors。
  • ALLOW-FROM 的问题： ALLOW-FROM 指令存在兼容性问题，且容易配置错误。如果攻击者能够控制被允许的URI，或者利用其子域的漏洞，仍然可能绕过防御。因此，不推荐使用 ALLOW-FROM。

2.4 与 Content-Security-Policy (CSP) frame-ancestors 指令的协同

Content-Security-Policy (CSP) 是一种更全面、更灵活的安全策略，它允许网站管理员通过定义一系列源来限制浏览器加载资源（脚本、样式、图片、字体等）。CSP 规范中引入了 frame-ancestors 指令，它提供了与 X-Frame-Options 类似但更强大的功能，用于控制哪些父级页面可以嵌入当前页面。

frame-ancestors 语法：

Content-Security-Policy: frame-ancestors 'self' https://trusted.example.com;

或

Content-Security-Policy: frame-ancestors 'none';
  • 'self'： 允许同源的页面嵌入。
  • 'none'： 禁止任何页面嵌入（等同于 X-Frame-Options: DENY）。
  • uri： 允许指定的URI嵌入。可以指定多个URI，支持通配符（如 *.example.com）。

优先级：
根据CSP规范，如果同时存在 X-Frame-Options 和 Content-Security-Policy 中的 frame-ancestors 指令，那么 frame-ancestors 将优先生效。这意味着，如果你已经配置了 frame-ancestors，那么 X-Frame-Options 的设置将被忽略。

推荐策略：
鉴于 frame-ancestors 的灵活性和作为更广泛安全策略的一部分，强烈建议使用 Content-Security-Policy 的 frame-ancestors 指令来代替或补充 X-Frame-Options。它不仅能防御点击劫持，还能提供其他多方面的安全防护。

CSP frame-ancestors 实现示例：

Nginx:

server {
    listen 80;
    server_name example.com;

    # 禁止任何网站嵌入此页面
    add_header Content-Security-Policy "frame-ancestors 'none'";

    # 或者，只允许同源或指定域名嵌入
    # add_header Content-Security-Policy "frame-ancestors 'self' https://trusted-partner.com";

    location / {
        # ...
    }
}

Node.js (Express 与 Helmet):

const express = require('express');
const helmet = require('helmet');
const app = express();

app.use(helmet.contentSecurityPolicy({
  directives: {
    // ... 其他CSP指令 ...
    frameAncestors: ["'none'"], // 禁止任何网站嵌入
    // 或者 frameAncestors: ["'self'", "https://trusted-partner.com"], // 允许同源和指定域名
  },
}));

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

总而言之，X-Frame-Options 是一个可靠且易于部署的点击劫持防御手段。对于只需要简单禁止或允许同源嵌入的场景，它非常有效。而 Content-Security-Policy 的 frame-ancestors 则提供了更细粒度的控制，并且是现代Web安全实践的首选。

3. 防御机制二：Frame Busting 脚本 (客户端防御)

在 X-Frame-Options 和 CSP frame-ancestors 出现之前，或者作为一种额外的深度防御层，客户端的 JavaScript “破框”（Frame Busting）脚本是抵御点击劫持的主要手段。这些脚本的目标是检测页面是否被嵌入到框架中，如果是，则尝试将自身从框架中“跳出”，让整个浏览器窗口导航到当前页面。

3.1 经典 Frame Busting 脚本

最基本的破框脚本非常简单，它依赖于 window 对象的两个属性：self 和 top。

  • window.self 指向当前窗口或框架。
  • window.top 指向最顶层的浏览器窗口。

如果 self 不等于 top，说明当前页面被嵌入在框架中。在这种情况下，脚本会尝试将 top.location 设置为 self.location，从而强制整个页面跳出框架。

<!-- victim.html (受害者页面) -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>我的安全页面</title>
    <script>
        // 经典的破框脚本
        if (window.self !== window.top) {
            try {
                // 尝试将顶层窗口重定向到当前页面的URL
                // 这将使当前页面跳出iframe，占据整个浏览器窗口
                window.top.location = window.self.location;
            } catch (e) {
                // 如果 top.location 访问被同源策略阻止 (例如，攻击者页面是不同源的)
                // 此时无法跳出，可以考虑显示警告信息或隐藏敏感内容
                console.warn("无法跳出框架，可能受到点击劫持攻击。错误信息:", e);
                // 进一步的防御措施：隐藏页面内容
                document.documentElement.style.display = 'none';
            }
        }
    </script>
    <style>
        body { font-family: Arial, sans-serif; padding: 20px; }
        .sensitive-content {
            border: 1px solid red;
            padding: 15px;
            margin-top: 20px;
            background-color: #ffe0e0;
        }
    </style>
</head>
<body>
    <h1>欢迎来到我的账户管理页面</h1>
    <p>这里有一些重要的操作。</p>
    <button onclick="alert('执行了重要操作！')">执行重要操作</button>
    <div class="sensitive-content">
        您已登录，您的余额是：<strong>1,000,000,000 USD</strong>
        <button onclick="alert('转账操作被触发！')">确认转账</button>
        <button onclick="alert('删除账户操作被触发！')">删除账户</button>
    </div>
</body>
</html>

3.2 Frame Busting 脚本的局限性与绕过技术

尽管经典脚本看似有效，但攻击者们很快就发现了一些巧妙的绕过方法。这些绕过技术主要利用了浏览器的一些特性或JavaScript的执行机制。

3.2.1 onbeforeunload / onunload 事件绕过

原理： 攻击者在自己的恶意页面中，在加载受害者页面后，立即为 <iframe> 内部的 window 对象（即受害者页面的 window）注册一个 onbeforeunload 或 onunload 事件处理函数。当受害者页面尝试通过 top.location = self.location 跳出框架时，这会触发 onbeforeunload 事件。攻击者可以在这个事件处理函数中返回一个空字符串或取消导航，从而阻止页面跳转。

攻击者页面示例：

<!-- attacker.html -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>点击劫持攻击</title>
</head>
<body>
    <iframe id="victimFrame" src="https://victim.com/victim.html" style="width:100%; height:100%; opacity:0.0001;"></iframe>
    <script>
        const victimFrame = document.getElementById('victimFrame');
        victimFrame.onload = function() {
            try {
                // 尝试访问iframe的contentWindow并设置onbeforeunload
                // 注意：由于同源策略，如果victim.com与attacker.com不同源，
                // 攻击者将无法直接访问 contentWindow 的大部分属性和方法。
                // 这个绕过在现代浏览器中，由于严格的同源策略，通常难以实现，
                // 但在某些旧版本浏览器或特定配置下可能有效。
                if (victimFrame.contentWindow) {
                    victimFrame.contentWindow.onbeforeunload = function() {
                        // 返回一个字符串会显示一个提示框，询问用户是否离开页面
                        // 这可以阻止受害者页面的跳出行为
                        return "您确定要离开此页面吗？";
                    };
                    // 或者更直接地，尝试阻止导航 (虽然通常被浏览器阻止)
                    // victimFrame.contentWindow.onunload = function() { /* do nothing */ };
                }
            } catch (e) {
                console.error("无法访问iframe内容或设置onbeforeunload:", e);
            }
        };
    </script>
    <div style="position:absolute; top:200px; left:300px; z-index:10; background:red; color:white;">
        点击这里赢取大奖！
    </div>
</body>
</html>

防御思考： 现代浏览器对跨域的 contentWindow 访问有严格限制，这种攻击通常难以成功。但在同源框架嵌套或某些特定场景下，仍需警惕。

3.2.2 sandbox 属性绕过

原理： HTML5的 <iframe> 元素引入了 sandbox 属性，它允许开发者对 <iframe> 中的内容施加额外的安全限制。攻击者可以在 <iframe> 标签上使用 sandbox 属性，并省略 allow-top-navigation 关键字，从而阻止框架内的页面导航顶层窗口。

攻击者页面示例：

<!-- attacker.html -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>点击劫持攻击 - Sandbox</title>
</head>
<body>
    <!--
        sandbox 属性：
        allow-scripts: 允许执行脚本
        allow-forms: 允许提交表单
        allow-same-origin: 允许同源访问（对于victim.com来说，它内部的脚本可以访问自己的DOM）

        关键在于缺少 'allow-top-navigation'，这将阻止 iframe 内部的脚本导航父级窗口。
    -->
    <iframe id="victimFrame" 
            src="https://victim.com/victim.html" 
            sandbox="allow-scripts allow-forms allow-same-origin" 
            style="width:100%; height:100%; opacity:0.0001;"></iframe>

    <div style="position:absolute; top:200px; left:300px; z-index:10; background:green; color:white;">
        点击这里领取福利！
    </div>
</body>
</html>

当 victim.html 中的 Frame Busting 脚本执行 window.top.location = window.self.location; 时，浏览器会因为 sandbox 属性的限制而阻止这个操作，并可能抛出安全错误。

防御思考： sandbox 属性是针对父框架的，受害者页面无法控制父框架是否使用 sandbox。这是 Frame Busting 脚本的一个根本性弱点。

3.2.3 嵌套框架绕过

原理： 攻击者可以创建一个两层嵌套的框架。外层框架是攻击者的页面，内层框架加载受害者页面。当受害者页面中的破框脚本执行 top.location = self.location 时，它只会跳出到直接的父框架（即攻击者创建的外层框架），而不是最顶层的浏览器窗口。

攻击者页面示例：

<!-- attacker.html -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>点击劫持攻击 - 嵌套框架</title>
</head>
<body>
    <iframe id="outerFrame" srcdoc='
        <!DOCTYPE html>
        <html>
        <head>
            <title>Outer Frame</title>
        </head>
        <body>
            <!-- 内层 iframe 加载受害者页面 -->
            <iframe id="innerFrame" 
                    src="https://victim.com/victim.html" 
                    style="width:100%; height:100%; border:none; opacity:0.0001;"></iframe>
            <div style="position:absolute; top:200px; left:300px; z-index:10; background:orange; color:white;">
                点击这里激活账户！
            </div>
        </body>
        </html>
    ' style="width:100%; height:100%; border:none;"></iframe>
</body>
</html>

在这个例子中，victim.html 里面的 window.top 将是 outerFrame 的 window 对象，而不是最外层的浏览器窗口。因此，victim.html 只能跳出到 outerFrame，而攻击者仍然可以控制 outerFrame 的显示，从而继续进行点击劫持。

防御思考： 这种绕过方式揭示了 window.top !== window.self 判断的局限性。它只判断了是否被框架化，但无法判断是否被最顶层框架所包围。

3.2.4 location.hash 绕过

原理： 攻击者可以利用浏览器处理 location.hash 的特性。当 top.location 被设置为 self.location 时，如果 self.location 包含一个哈希值（例如 victim.com/page#anchor），并且攻击者在顶层页面的URL中也包含了相同的哈希值，某些旧版浏览器可能会认为URL没有变化，从而阻止导航。

攻击者页面示例 (理论，现代浏览器修复了):

<!-- attacker.html?#anchor -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>点击劫持攻击 - Hash</title>
</head>
<body>
    <iframe src="https://victim.com/victim.html#somehash" style="width:100%; height:100%; opacity:0.0001;"></iframe>
    <script>
        // 攻击者页面加载时，URL可能已经是 attacker.com/#somehash
        // 这样当 iframe 内部尝试导航到 victim.com/victim.html#somehash 时
        // 浏览器可能认为顶层URL的hash部分没有变化，从而忽略导航请求
    </script>
</body>
</html>

防御思考： 这是一个较为古老的绕过技术，现代浏览器已对此进行了修复，不再构成主要威胁。

3.3 更健壮的 Frame Busting 策略

鉴于上述绕过技术的存在，为了使 Frame Busting 脚本更具韧性，可以采取一些更复杂的策略。然而，需要强调的是，客户端脚本的防御始终不如服务器端HTTP头（X-Frame-Options 或 CSP frame-ancestors）可靠。它们应被视为一种补充或回退机制。

3.3.1 CSS + JavaScript 组合防御 (快速隐藏)

这种方法结合了CSS的快速响应和JavaScript的逻辑判断，以期在脚本执行前快速隐藏页面内容。

CSS部分： 在 head 标签的顶部放置一段CSS，默认隐藏页面内容。

<!-- victim.html -->
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <title>我的安全页面</title>
    <style>
        /* 默认隐藏整个body，防止内容过早渲染 */
        body { display: none !important; }
    </style>
    <script>
        // 在脚本开始时，立即判断是否被框架化
        if (window.self === window.top) {
            // 如果不在框架中，则显示页面内容
            document.documentElement.style.display = 'block'; // 或 'initial' 或移除样式
            document.body.style.display = 'block'; // 确保body也显示
        } else {
            // 如果在框架中，尝试跳出
            try {
                // 更严格的检查：确保父级和自己不是同一个源 (防止同源iframe的误判)
                // 即使同源，如果父级是攻击者控制的，也应该跳出
                if (window.top.location.hostname !== window.self.location.hostname) {
                    window.top.location = window.self.location;
                } else {
                    // 如果同源，但仍然是框架，可能需要进一步判断是否允许
                    // 暂时保持隐藏，直到明确允许
                    document.documentElement.style.display = 'none';
                    document.body.style.display = 'none';
                }
            } catch (e) {
                // 无法访问 top.location (跨域或沙箱限制)
                // 此时页面被困在框架中，保持隐藏或显示警告
                console.warn("无法跳出框架，内容保持隐藏。错误信息:", e);
                document.documentElement.style.display = 'none';
                document.body.style.display = 'none';
            }
        }
    </script>
    <!-- 其他样式和内容 -->
</head>
<body>
    <!-- 页面内容 -->
</body>
</html>

工作原理：

  1. 页面加载时，CSS规则会立即隐藏 body，阻止任何内容的渲染。
  2. JavaScript脚本立即执行。
  3. 如果脚本检测到页面不在框架中（window.self === window.top），它会移除隐藏样式，使页面正常显示。
  4. 如果页面在框架中，脚本会尝试跳出。如果跳出失败（例如，由于 sandbox 属性或同源策略阻止了 top.location 的访问），页面将保持隐藏状态，阻止攻击者利用。

这种方法被称为“FOUC”（Flash of Unstyled Content）的逆向应用，即“FOUB”（Flash of Undesired Behavior）的防御。它确保了在确认安全之前，敏感内容不会被暴露。

3.3.2 循环检测与重定向

为了对抗 onbeforeunload 等事件的竞争条件，可以尝试在循环或定时器中反复尝试重定向。

// victim.html (部分代码)
<script>
    function frameBuster() {
        if (window.self !== window.top) {
            try {
                // 尝试重定向
                window.top.location = window.self.location;
            } catch (e) {
                // 如果第一次尝试失败，可能是沙箱或onbeforeunload
                // 可以在这里记录日志或执行其他防御
                console.warn("第一次跳出尝试失败:", e);
                // 此时页面可能仍被困在框架中，保持内容隐藏
                document.documentElement.style.display = 'none';
                document.body.style.display = 'none';
            }
        } else {
            // 如果不在框架中，显示内容
            document.documentElement.style.display = 'block';
            document.body.style.display = 'block';
        }
    }

    // 在页面加载时执行
    frameBuster();
    // 也可以在定时器中重复执行，以对抗某些竞争条件
    // setInterval(frameBuster, 1000); // 谨慎使用，可能导致无限重定向循环
</script>

注意： 循环检测需要非常谨慎，如果 top.location 始终不可写，可能会导致无限循环，消耗资源或影响用户体验。通常，一次性尝试并辅以隐藏内容是更好的选择。

3.3.3 隐藏敏感操作元素

除了隐藏整个页面，也可以仅隐藏页面上的敏感操作元素，直到确认页面不在框架中。

<!-- victim.html (部分代码) -->
<style>
    /* 默认隐藏所有带有 'sensitive-action' 类的元素 */
    .sensitive-action { display: none !important; }
</style>
<script>
    if (window.self === window.top) {
        // 如果不在框架中，显示敏感操作元素
        document.querySelectorAll('.sensitive-action').forEach(el => {
            el.style.display = 'block'; // 或 'initial'
        });
        document.body.style.display = 'block'; // 确保body也显示
    } else {
        try {
            window.top.location = window.self.location;
        } catch (e) {
            console.warn("无法跳出框架，敏感操作保持隐藏。");
            // 此时页面内容可以显示，但敏感操作按钮保持隐藏
            document.body.style.display = 'block'; // 仅显示非敏感内容
        }
    }
</script>
<body>
    <h1>欢迎来到我的账户管理页面</h1>
    <p>这里有一些重要的操作。</p>
    <button class="sensitive-action" onclick="alert('执行了重要操作！')">执行重要操作</button>
    <div class="sensitive-content">
        您已登录，您的余额是：<strong>1,000,000,000 USD</strong>
        <button class="sensitive-action" onclick="alert('确认转账操作被触发！')">确认转账</button>
        <button class="sensitive-action" onclick="alert('删除账户操作被触发！')">删除账户</button>
    </div>
</body>

这种方法的优点是，即使页面无法跳出框架，用户仍然可以看到非敏感内容，但关键的、可能被劫持的操作按钮是隐藏的，降低了攻击的成功率。

3.4 客户端防御的总结

  • 优点：
    • 作为 X-Frame-Options 或 CSP frame-ancestors 的回退机制，为不支持这些HTTP头的旧浏览器提供防护。
    • 在服务器端无法控制HTTP头的情况下，提供唯一的防御手段。
  • 缺点：
    • 容易被绕过： 如上所述，存在多种绕过技术，使得客户端脚本的可靠性不如服务器端HTTP头。
    • JavaScript 依赖： 如果用户的浏览器禁用JavaScript，则此防御机制将完全失效。
    • 用户体验问题： 强制重定向可能导致页面闪烁或重新加载，影响用户体验。
    • 安全错误： 跨域访问 top.location 可能会抛出安全错误，需要妥善处理。

4. 最佳实践与推荐

在深入了解了点击劫持的防御机制后，我们来总结一下在实际项目中应该采取的最佳实践。

4.1 优先使用服务器端 HTTP 响应头

毫无疑问，服务器端配置的 X-Frame-Options 或 Content-Security-Policy 的 frame-ancestors 指令是抵御点击劫持最强大、最可靠的方式。 它们直接由浏览器内核强制执行，几乎不可能被客户端脚本绕过。

  • 推荐： Content-Security-Policy: frame-ancestors 'none'; 或 Content-Security-Policy: frame-ancestors 'self' https://trusted.example.com;
  • 次之（兼容性考虑）： X-Frame-Options: DENY; 或 X-Frame-Options: SAMEORIGIN;

如果你的应用不需要被任何其他网站嵌入，那么 DENY 或 frame-ancestors 'none' 是最安全的。如果需要同源嵌入，则选择 SAMEORIGIN 或 frame-ancestors 'self'。

4.2 结合客户端 Frame Busting 脚本作为深度防御

尽管客户端脚本存在局限性，但作为一种深度防御（Defense-in-Depth）策略，它仍然有其价值。它可以为不支持上述HTTP头的极少数旧浏览器提供一定程度的保护，或者在某些特殊情况下，为服务器端配置失误提供一层额外的屏障。

  • 推荐策略： 结合 CSS 预隐藏和 JavaScript 检测跳出。即，在 <head> 中使用 <style> 默认隐藏页面内容，然后在 JavaScript 中检测是否被框架化：如果不在框架中则显示内容；如果在框架中则尝试跳出，如果跳出失败则保持内容隐藏。

4.3 利用 SameSite Cookies 缓解攻击影响

虽然 SameSite Cookie 属性不是直接的点击劫持防御机制，但它可以显著缓解点击劫持攻击的潜在影响。

  • SameSite=Lax (默认)： 大多数现代浏览器默认将没有 SameSite 属性的Cookie视为 Lax。这意味着在跨站请求中，只有顶层导航和通过 GET 方法发起的请求会发送Cookie。对于 <iframe> 内部的跨站请求（通常是 POST 或其他方法），Cookie不会被发送，从而阻止攻击者利用用户已登录的会话进行敏感操作。
  • SameSite=Strict： 这是最严格的选项，它完全禁止在跨站请求中发送Cookie，即使是顶层导航也不发送。这提供了更强的防护，但可能会影响一些正常的跨站链接跳转体验。

实施建议： 确保所有敏感的会话Cookie和CSRF Token Cookie都设置了 SameSite=Lax 或 Strict。

4.4 安全意识与开发流程

  • 开发者教育： 确保开发团队了解点击劫持的风险以及如何正确实施防御措施。
  • 安全审计： 定期进行安全审计和渗透测试，检查是否存在点击劫持漏洞，以及防御措施是否正确配置和有效。
  • 自动化检查： 将 X-Frame-Options 或 CSP frame-ancestors 的存在和正确性集成到CI/CD流程中，进行自动化检查。

5. 综合对比分析

为了更清晰地理解这几种防御机制的特点，我们通过一个表格进行对比：

特性 X-Frame-Options HTTP Header CSP frame-ancestors 指令 Frame Busting 脚本 (JS)
类型 服务器端 HTTP 响应头 服务器端 HTTP 响应头 客户端 JavaScript
强制执行点 浏览器内核 浏览器内核 浏览器 JavaScript 引擎
控制粒度 低 (DENY, SAMEORIGIN) 高 ('none', 'self', 特定URI, 通配符) 低 (是/否被框架化)
可靠性 极高 (现代浏览器) 极高 (现代浏览器) 中等 (易被绕过)
浏览器支持 广泛 (IE8+ 及所有现代浏览器) 良好 (主要现代浏览器) 普遍 (JS启用即可，但绕过普遍)
部署难度 简单 (一行配置) 中等 (需理解CSP语法，可能涉及其他指令) 简单 (基础脚本)，复杂 (健壮脚本)
性能影响 忽略不计 忽略不计 极小 (脚本执行)
主要优点 简单、高效、浏览器原生支持 灵活、强大、作为更广泛CSP的一部分 作为回退，适用于旧浏览器或无法控制服务器头的情况
主要缺点 粒度不足，ALLOW-FROM 已废弃 语法复杂，旧浏览器支持可能不足 易被绕过，依赖JS，可能影响用户体验
推荐状态 良好，但推荐升级到CSP 强烈推荐作为首选防御 推荐作为深度防御的补充层

从上表可以看出，Content-Security-Policy 的 frame-ancestors 指令是目前最推荐的点击劫持防御手段。它不仅提供了最灵活的控制，而且作为浏览器原生安全机制的一部分，其可靠性远超客户端JavaScript。

结语

点击劫持是一个持续存在的Web安全威胁，它利用了浏览器渲染机制和用户界面信任的盲区。幸运的是，我们拥有强大的防御工具。服务器端的 X-Frame-Options HTTP响应头和更现代、更灵活的 Content-Security-Policy 的 frame-ancestors 指令是我们的首要防线，它们提供了坚不可摧的保护。而客户端的 Frame Busting 脚本，尽管其自身存在局限性并容易被绕过，但作为一种深度防御策略，仍然可以为我们的应用程序提供额外的安全层。

理解这些机制的原理、实现方式及其局限性，并根据应用程序的具体需求选择最合适的防御组合，是每一位编程专家在构建安全Web应用时不可或缺的技能。始终记住，安全是一个持续的过程，而非一次性配置，保持警惕，不断学习和更新防御策略至关重要。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注