数据库全局临时表与防止SQL注入的会话隔离

数据库全局临时表（Global Temporary Table，简称GTT）本身并不能直接防止SQL注入，但它在会话隔离层面提供了一种天然的数据边界机制，配合参数化查询和正确的权限控制，可以显著降低SQL注入攻击的危害范围。简单来说，全局临时表的数据对每个会话是独立可见的，攻击者即便通过注入拿到了某些操作权限，他能触及的也只是自己会话内的临时数据，而不是其他用户的业务数据。这就是"会话隔离"的核心价值——把爆炸半径控制在最小范围内。

很多开发者在做安全防护时，只盯着参数化查询和输入过滤，却忽略了数据库层面的结构性隔离手段。全局临时表恰恰是一个被低估的安全辅助工具。下面我会从原理、实现、安全价值、实际应用场景几个维度，把这件事讲透。

全局临时表是一种特殊的数据库表，它的表结构是全局共享的（所有会话都能看到表定义），但表中的数据是会话级别隔离的。每个数据库会话（Session）只能看到自己插入的数据，其他会话的数据完全不可见。当会话结束时，数据自动清除，不需要手动清理。

以Oracle为例，创建全局临时表的语法如下：

CREATE GLOBAL TEMPORARY TABLE gtt_session_data (
    id          NUMBER PRIMARY KEY,
    session_key VARCHAR2(128),
    payload     CLOB,
    created_at  TIMESTAMP DEFAULT SYSTIMESTAMP
) ON COMMIT PRESERVE ROWS;

这里的关键参数是"ON COMMIT PRESERVE ROWS"和"ON COMMIT DELETE ROWS"。前者表示事务提交后数据保留，只在会话断开时清除；后者表示每次事务提交都清空。根据安全需求选择不同策略，通常推荐使用PRESERVE ROWS，因为你可能需要在一个会话内多次操作临时数据。

在SQL Server中，全局临时表以双井号开头：

CREATE TABLE ##GlobalTempData (
    Id INT IDENTITY(1,1) PRIMARY KEY,
    UserToken VARCHAR(256),
    TempValue NVARCHAR(MAX),
    InsertTime DATETIME DEFAULT GETDATE()
);

在PostgreSQL中，虽然没有原生的全局临时表概念，但可以通过模式（Schema）加临时表的组合来模拟类似效果：

CREATE TEMP TABLE session_isolated_data (
    id SERIAL PRIMARY KEY,
    token TEXT,
    data JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
) ON COMMIT PRESERVE ROWS;

会话隔离的本质是数据库引擎在内部维护了一张"会话-数据"的映射表。当你向全局临时表插入数据时，数据库会自动把这条记录标记为当前会话所有。其他会话执行SELECT时，引擎会过滤掉不属于自己的记录。这个过程对应用层完全透明，开发者不需要手动加WHERE条件。

具体来说，隔离机制依赖三个层面：

第一层是连接级别的标识。每个数据库连接都有唯一的Session ID或SPID，引擎用这个ID来区分数据归属。

第二层是事务上下文。在ON COMMIT DELETE ROWS模式下，事务边界就是数据生命周期的边界；在PRESERVE ROWS模式下，会话断开才是终点。

第三层是权限过滤。即使表结构全局可见，数据访问层面已经被引擎层自动拦截。这比应用层做权限判断更可靠，因为它在存储引擎内部完成，不依赖应用代码的正确性。

必须先澄清一个事实：全局临时表不能替代参数化查询。SQL注入的根本防御手段永远是参数化查询（Prepared Statement）和输入验证。全局临时表的价值在于"纵深防御"——即便攻击者通过某种方式绕过了前端防护（比如利用了存储过程中的动态SQL拼接漏洞），他能造成的破坏也被限制在自己的会话空间内。

举个实际场景：假设你的系统有一个报表导出功能，用户可以自定义筛选条件。如果后端用字符串拼接的方式构造SQL：

String sql = "SELECT * FROM gtt_report_filter WHERE user_id = " + userInput + " AND status = '" + statusInput + "'";

攻击者可以注入恶意代码。但如果这个查询操作的目标表是全局临时表，攻击者最多只能往自己的临时表空间里塞垃圾数据或执行一些受限操作，他无法通过这个入口去读取或修改其他用户的业务表数据。因为临时表的数据本身就是隔离的，注入的影响范围被物理限制住了。

更关键的是，全局临时表通常不会被授予高权限。DBA在设计时会把临时表放在独立的表空间，给予最小必要权限。攻击者即便拿到了执行权限，也无法通过临时表去做DROP TABLE、ALTER SYSTEM这类高危操作。

真正安全的做法是把全局临时表和参数化查询结合起来使用。下面是一个完整的安全设计思路：

步骤一：所有用户输入必须通过参数化查询传入，绝不在应用层拼接SQL。

PreparedStatement ps = connection.prepareStatement(
    "INSERT INTO gtt_user_session (token, data) VALUES (?, ?)"
);
ps.setString(1, sessionToken);
ps.setString(2, encryptedPayload);
ps.executeUpdate();

步骤二：使用全局临时表存放会话中间数据，而不是用普通业务表。这样即使参数化查询被意外破坏（比如代码维护时有人改成了拼接），数据泄露的范围也仅限于当前会话。

步骤三：在存储过程中使用临时表做数据中转，避免动态SQL直接操作核心业务表。

CREATE OR REPLACE PROCEDURE safe_data_process(p_input IN VARCHAR2)
IS
BEGIN
    -- 先把输入放入临时表，做清洗和验证
    INSERT INTO gtt_input_buffer (raw_input, processed_flag)
    VALUES (p_input, 'N');

    -- 在临时表上做安全的数据处理
    UPDATE gtt_input_buffer
    SET processed_flag = 'Y',
        clean_value = REGEXP_REPLACE(raw_input, '['';]--', '')
    WHERE processed_flag = 'N';

    -- 只把清洗后的数据写入业务表
    INSERT INTO business_table (final_value)
    SELECT clean_value FROM gtt_input_buffer WHERE processed_flag = 'Y';

    -- 清理临时数据
    DELETE FROM gtt_input_buffer;
END;
/

步骤四：设置会话超时和连接池隔离，确保每个应用连接对应独立的数据库会话，防止会话劫持后数据串访。

不同数据库对全局临时表的实现和安全控制有差异，选型时需要注意：

Oracle的全局临时表是最成熟的实现，数据隔离在引擎层完成，支持PRESERVE和DELETE两种模式，且临时表的数据不会写入重做日志（Redo Log），性能好且不影响备份策略。安全方面，Oracle允许对临时表单独授权，可以精确控制谁能写入、谁能读取。

SQL Server的全局临时表（##开头）在所有会话间共享，但数据同样是会话隔离的。需要注意的是，SQL Server的临时表如果创建在tempdb中，重启后会清空，但会话内的数据隔离机制和Oracle类似。安全上要注意tempdb的权限配置，避免低权限用户通过临时表做提权操作。

PostgreSQL的临时表是会话级别的，严格来说不算"全局"临时表，因为其他会话根本看不到这个表的定义。但可以通过创建公共Schema下的临时表来模拟。PostgreSQL的优势是临时表完全不写WAL日志，崩溃恢复时不需要处理临时表数据，天然安全。

MySQL在8.0版本之前没有真正的全局临时表，只能用普通表加会话变量模拟；

8.0之后引入了CREATE TEMPORARY TABLE，但同样是会话级别可见。如果需要跨会话共享表结构但隔离数据，需要自己在应用层做控制。

场景一：多租户SaaS系统。每个租户的数据处理可以先写入各自的全局临时表，做完清洗和校验后再合并到公共业务表。这样即使某个租户的输入有注入代码，影响的也只是他自己的临时表空间。

场景二：批量数据导入。用户上传CSV或Excel文件时，先把数据加载到全局临时表，在临时表上做格式校验、去重、转换，确认无误后再写入正式表。这个过程中如果导入逻辑有SQL拼接漏洞，攻击者也只能污染临时表。

场景三：复杂报表查询。用户自定义的查询条件先存入临时表，然后用存储过程基于临时表数据生成报表。存储过程内部使用参数化查询，临时表作为数据缓冲层，双重保护。

架构建议：在设计数据库安全体系时，把全局临时表作为"安全缓冲区"纳入整体方案。不要只依赖应用层防护，要在数据库层也建立隔离墙。具体做法是：核心业务表拒绝直接接受用户输入，所有用户输入必须先经过临时表中转，中转过程中完成清洗和验证。

误区一：认为用了全局临时表就不需要参数化查询。这是危险的想法。临时表只是缩小了爆炸半径，并不能阻止注入本身。如果攻击者在临时表上执行了DROP TABLE或者通过临时表做了权限提升，照样有危害。

误区二：认为临时表数据不重要所以不用备份。虽然临时表数据会话结束就没了，但如果你的业务逻辑依赖临时表中的中间结果，会话异常断开可能导致数据丢失。建议在关键流程中加持久化兜底。

误区三：忽略临时表的表空间管理。大量并发会话同时使用全局临时表，可能导致临时表空间膨胀。需要设置合理的表空间配额和自动清理策略。

注意事项：始终遵循最小权限原则，给应用账号只授予临时表的INSERT和SELECT权限，不给DROP、ALTER、TRUNCATE权限。定期审计临时表的使用情况，监控异常的大批量写入行为。

数据库全局临时表不是SQL注入的银弹，但它是纵深防御体系中一个非常实用的组件。通过会话级别的数据隔离，它把潜在的注入危害限制在最小范围内。配合参数化查询、最小权限原则和合理的架构设计，全局临时表能让你的系统在面对注入攻击时多一层坚固的防线。安全从来不是单一手段能解决的问题，而是多层机制协同工作的结果。把全局临时表用对、用好，是每一个注重数据库安全的团队都应该掌握的基本功。