PHP tmpfile()竞争条件漏洞剖析：从临时文件替换到反序列化投毒

1. tmpfile()到底干了什么：从机制上理解这个坑

1.1 tmpfile()的工作流程与安全假设

PHP的tmpfile()函数是一个很常用的临时文件生成工具，它做的事情是：在系统临时目录下创建一个唯一的临时文件，返回一个文件句柄，并且当这个句柄被关闭或者脚本执行结束时，文件会自动删除。看似很方便，很多开发者处理上传、缓存、导出数据时会直接用它。

但这里藏着一个容易被人忽略的安全假设：tmpfile()创建文件时使用的是系统默认临时目录（在Linux下通常是/tmp），文件名通过随机算法生成，函数本身确实做了随机化处理，不同PHP版本使用的随机源和强度不一致，但重点不在文件名强度上，而在于另外两个问题。

第一个问题是，tmpfile()不会帮你校验临时目录的安全性。/tmp目录是个全局可写的目录，任何用户都能在这个目录里创建文件，这就意味着攻击者可以提前在/tmp下做手脚。第二个问题是，你拿到的是文件句柄（resource），而不是文件路径。很多人以为拿到句柄就安全了，却不知道文件句柄和文件路径之间存在一个可以被利用的时间窗口。

这个函数的安全模型是：随机文件名足够强，攻击者无法预测文件名，因此无法提前对文件进行操作。这个模型在理论上是成立的，但在实际部署环境中会因为文件系统行为和目录权限设置被打破。当/tmp目录没有开启粘滞位（sticky bit），或者攻击者能通过其他途径预测文件名的生成规律时，这个安全假设就会崩塌。

1.2 竞争条件为什么会发生

竞争条件（Race Condition）在并发场景下才会出现，但PHP脚本本身常常被认为是单线程的，很多人因此忽视了它。实际上PHP-FPM是并发处理请求的，多个请求可以同时执行到同一段代码。即便不考虑PHP并发，攻击者也可以通过另一段独立代码（比如命令行脚本、其他语言写的守护进程）来与目标PHP脚本并行执行，竞争窗口依然存在。

tmpfile()和fopen()这类函数遵循的操作流程是：生成随机文件名 -> 创建文件 -> 返回句柄。这个三步操作之间并不是原子的。攻击者的核心做法是：在第一步和第二步之间插入自己的操作，提前创建一个同名的符号链接（symlink），把目标路径指向攻击者控制的文件内容。

一旦tmpfile()在第二步尝试创建文件时，发现目标路径已经存在，它会如何处理？这取决于PHP的底层实现和系统调用方式。在绝大多数Linux发行版上，tmpfile()底层使用open(O_CREAT | O_EXCL)的方式来创建文件，这个标志位要求文件必须是不存在的，如果存在则创建失败。但有些异常情况下，如果文件创建成功后、还没写入内容的时候，你获得了句柄，攻击者完全无法操作这个句柄，因为句柄对应的inode已经固定了。

所以真正危险的场景不是tmpfile()自己创建的文件被替换，而是：攻击者通过符号链接预测文件名，让tmpfile()创建失败或者创建到攻击者指定的位置。还有一种情况更容易被忽略，就是PHP配置里改了sys_temp_dir，指向了一个不安全的目录，导致tmpfile()的行为发生变化，这里面的细节我在后面的修复方案里会展开讲。

2. 攻击路径复现：临时文件被替换的完整推演

2.1 攻击第一步：预创建符号链接

我来演示一个实际可运行的攻击验证流程。假设目标系统上运行着一段使用tmpfile()处理用户上传数据的PHP代码，攻击者的目标是让PHP脚本读取到的内容来自攻击者伪造的文件，而不是真正的临时文件。

攻击者的第一步是创建大量符号链接，指向自己控制的文件。这里的难点在于文件名是随机生成的，攻击者并不知道tmpfile()会产生什么文件名。但有几种情况会让文件名变得可预测：一是PHP版本偏老，随机数生成强度不足；二是系统熵源不足，导致随机数重复；三是某些PHP框架或开发者在tmpfile()外层包了一层自定义封装，改变了文件名的生成规则。

实际的攻击脚本通常长这样：

bash复制#!/bin/bash
# 预先创建符号链接，指向攻击者控制的伪造文件
for i in $(seq 1 10000); do
    ln -s /tmp/attacker_controlled_content /tmp/phpXXXXXX$i 2>/dev/null
done

这段bash脚本的做法是，在/tmp目录下批量创建大量的符号链接。当PHP的tmpfile()尝试创建一个恰好落在这个文件名的文件时，由于路径已经存在（符号链接也属于已存在的路径），创建动作会被拒绝，此时PHP会产生一个Warning，tmpfile()返回false，脚本逻辑可能走向攻击者期望的异常分支。

如果你觉得这个攻击方式过于依赖运气，那换个场景就清晰了：当开发者使用tmpfile()生成一个文件，然后又把文件路径传给了另一个函数进行处理，比如在Windows环境下遇到需要传递路径的情况，这时开发者很可能自己去拼接路径，伪代码大概是这样的：

php复制<?php
$tmp = tmpfile();
$path = sys_get_temp_dir() . '/myapp_' . session_id() . '.tmp';
// 注意：这里并没有把$tmp的路径和$path关联起来
file_put_contents($path, $data);

这种写法的问题在于：开发者完全绕开了tmpfile()的安全机制，使用了一个可预测、可猜测的文件名（session_id()通常可以通过Cookie获取或者被攻击者操控）。攻击者只需要提前创建符号链接，就能让file_put_contents()操作到任意路径，从而实现任意文件写入。

2.2 攻击第二步：在竞争窗口内替换文件

预创建符号链接只是攻击方式的一种，更复杂的攻击是在竞争窗口内做实时替换。PHP的tmpfile()底层是先创建一个随机文件名，然后打开文件。这个窗口极小，通常只有微秒级，但攻击者可以利用inotify等文件系统监控机制来捕捉创建事件，然后在创建之后、内容写入之前进行干预。

这个场景听起来复杂，但实际上在本地文件系统上可以通过两个线程实现。一个线程持续监控/tmp目录下的新文件创建事件，另一个线程在检测到新文件出现后立即删除该文件并替换为符号链接。攻击脚本可以用Python实现，以下是核心逻辑：

python复制import inotify.adapters
import os
import threading

TMP_DIR = "/tmp"

def monitor_and_replace():
    i = inotify.adapters.Inotify()
    i.add_watch(TMP_DIR.encode())
    for event in i.event_gen(yield_nones=False):
        (_, type_names, path, filename) = event
        if 'IN_CREATE' in type_names:
            target = os.path.join(TMP_DIR.decode(), filename.decode())
            try:
                # 尝试立即删除刚创建的文件
                os.unlink(target)
                # 替换为指向攻击者文件的符号链接
                os.symlink("/tmp/attacker_file", target)
            except Exception:
                pass

def attacker():
    # 攻击者文件内容
    with open("/tmp/attacker_file", "w") as f:
        f.write("<?php system($_GET['cmd']); ?>")
    monitor_and_replace()

if __name__ == "__main__":
    attacker()

这个脚本的局限在于，PHP拿到文件句柄后，文件删除和替换并不能影响已经打开的文件描述符。真正的利用点是：在PHP打开文件之前完成替换，或者在PHP删除文件之后（如果后续代码重新打开同一路径）完成符号链接的植入。

实际代码审计中，我发现最容易出现问题的模式是这样的：先用tmpfile()拿到句柄，然后通过stream_get_meta_data($tmp)获取uri，再用这个uri作为路径去进行二次打开或者传递给下游工具。如果你在获取uri之后、二次打开之前有时间差，攻击者就能在这个时间差里做手脚。

2.3 危害场景：从文件内容篡改到反序列化投毒

临时文件被替换后能造成多大的危害，取决于业务代码怎么使用这个临时文件。最直接的危害是数据被篡改，临时文件中的内容被替换成攻击者伪造的内容，业务逻辑基于伪造内容做出错误判断。

更危险的场景是反序列化投毒。很多PHP框架会在临时文件中存放序列化的数据，比如缓存、Session、上传文件的中间处理内容。如果临时文件被替换成一段精心构造的phar文件或序列化字符串，后续代码调用unserialize()时就会触发PHP对象注入漏洞，攻击者可以借此执行任意代码。

搜索热词里提到"php反序列化漏洞"确实和本次话题高度相关，tempfile的竞争条件可能被用于投递反序列化payload。有一种常见路径是：PHP脚本将用户上传的临时文件移动到某个存储目录后，后续反序列化处理这个文件的内容。如果临时文件在移动前被替换，攻击者就能控制反序列化的数据源。

另一个危害场景是符号链接攻击导致任意文件读取。假设攻击者让tmpfile()的路径指向一个系统敏感文件，后续代码如果再对路径执行file_get_contents()或者include()，就会导致敏感文件内容泄露。这种情况下，即使PHP的tmpfile()函数本身没有漏洞，但业务代码对路径的处理方式放大了风险。

3. 修复方案详解：从禁用到安全的替代方案

3.1 方案一：放弃tmpfile()，改用自定义临时目录

最直接有效的方案是在业务代码中完全屏蔽tmpfile()的使用，改为在自定义的临时目录下创建文件。这个做法适合那些不需要跨进程共享临时文件的场景，PHP脚本自己创建、自己使用、自己删除。

推荐的做法是在项目根目录下创建一个临时目录，例如/storage/tmp，然后通过配置项指定，或者用常量定义。这个目录需要满足两个条件：一是PHP运行用户对它拥有完全控制权限（读写、创建、删除），二是它对其他系统用户不可写。

目录权限的正确设置方式是：

bash复制mkdir -p /www/wwwroot/myapp/storage/tmp
chown www:www /www/wwwroot/myapp/storage/tmp
chmod 700 /www/wwwroot/myapp/storage/tmp

然后把PHP的sys_temp_dir配置改成这个目录，或者通过代码动态指定：

php复制<?php
define('APP_TMP_DIR', dirname(__DIR__) . '/storage/tmp');
if (!is_dir(APP_TMP_DIR)) {
    mkdir(APP_TMP_DIR, 0700, true);
}

之后创建临时文件就用fopen()配合随机文件名，而不是直接用tmpfile()。文件名生成可以借助random_bytes()来保证足够的随机性和不可预测性：

php复制<?php
function create_secure_temp_file($prefix = 'app_') {
    $filename = APP_TMP_DIR . '/' . $prefix . bin2hex(random_bytes(16)) . '.tmp';
    $handle = fopen($filename, 'x+b');
    if ($handle === false) {
        throw new RuntimeException('无法创建临时文件');
    }
    return ['handle' => $handle, 'path' => $filename];
}

注意这里用了fopen()的'x'模式，它会强制要求文件不存在时才能创建成功，相当于带了O_EXCL标志，从机制上避免了符号链接提前占位的问题。同时因为目录是700权限，系统其他用户无法进入，也就无法对这个目录里的文件进行竞争操作。

采用这种方案后，临时文件不会自动删除了，需要自己管理文件生命周期。建议在处理逻辑的finally块中关闭句柄并删除文件，同时可以启动一个定期清理任务，清理超过一定时间未使用的临时文件。

3.2 方案二：对写入内容做严格校验与二次验证

如果不方便更换临时文件机制，仍然希望继续使用tmpfile()，那么至少需要增加严格的校验逻辑。校验的思路是：对临时文件写入内容后，读回内容进行完整性校验，校验的内容包括大小、哈希值、格式等。

最简单的校验方式是哈希一致性验证：

php复制<?php
$tmp = tmpfile();
fwrite($tmp, $data);
// 关键点：在写入后，不要马上信任这个文件
$stream_meta = stream_get_meta_data($tmp);
$actual_path = $stream_meta['uri'];
$actual_content = file_get_contents($actual_path);
if (hash_equals(md5($actual_content), md5($data)) === false) {
    // 内容不一致，说明文件可能被拦截或篡改
    fclose($tmp);
    throw new Exception('临时文件校验失败');
}

但说句实在话，这种校验在真正发生竞争条件攻击时作用有限。因为如果tmpfile()创建的文件从开始就被符号链接替代了，写入操作就会落到攻击者控制的文件上，读回来的内容自然就是伪造的。当然，如果你写入的是对称加密后的密文，攻击者无法伪造合法密文，那校验还是有意义的。但如果写入的是明文数据，攻击者完全可以篡改内容并让它通过哈希一致性校验（攻击者控制文件内容，就能控制哈希）。

所以正确的做法是：不能只做静态校验，要把校验和上下文绑定。比如，将写入数据时计算得到的哈希值放到一个安全位置（数据库中、Session中或者APCu缓存中），后续使用临时文件时，再从安全位置取哈希进行比对。即便攻击者篡改了文件内容，也无法同时修改安全位置中的哈希值。

这里需要强调一个标准：

所有对临时文件内容的信任，必须以临时文件路径不可被攻击者控制为前提。路径不可控，信任就不成立。

这句话是我做安全测试后总结的，建议直接写进团队编码规范里。

3.3 方案三：使用stream_get_meta_data()检查真实路径

PHP的tmpfile()返回的是一个资源类型，通过stream_get_meta_data()可以获取这个流的信息，其中uri字段表示这个流对应的路径。在有些PHP版本上，如果你用tmpfile()创建文件后执行stream_get_meta_data()，拿到的uri是类似"/tmp/phpXXXXXX"的形式，这个路径可以直接用。

有人会想：那我在拿到uri之后，检查这个uri是否是一个符号链接，如果发现是符号链接就拒绝处理，这不就安全了吗？这个思路有道理，但实施起来要谨慎。

检查符号链接的方法：

php复制<?php
$tmp = tmpfile();
$meta = stream_get_meta_data($tmp);
$path = $meta['uri'];
if (is_link($path)) {
    fclose($tmp);
    throw new Exception('临时文件被符号链接替换');
}
// 还需要检查路径所在的目录是否安全
$real_dir = realpath(dirname($path));
$safe_dir = realpath(sys_get_temp_dir());
if ($real_dir !== $safe_dir) {
    fclose($tmp);
    throw new Exception('临时文件目录异常');
}

这段代码在大多数情况下能拦截已经发生的符号链接替换。不过这个方法有一个盲区：检查通过后到实际使用文件前，仍存在一个时间窗口，攻击者可以在检查之后、读取之前替换文件。这也是TOCTOU（Time Of Check to Time Of Use）类漏洞的经典特征。

要提高安全性，可以在检查通过后立即对文件加锁，用flock()函数加上排他锁。这样即使攻击者替换了路径上的文件，也拿不到锁，后续代码在读取时因为有锁的保护，会等待或者拒绝。加锁的代码：

php复制<?php
$tmp = tmpfile();
$meta = stream_get_meta_data($tmp);
$path = $meta['uri'];
if (is_link($path)) {
    fclose($tmp);
    throw new Exception('临时文件被符号链接替换');
}
if (!flock($tmp, LOCK_EX | LOCK_NB)) {
    fclose($tmp);
    throw new Exception('临时文件加锁失败');
}

组合方案是：检查路径安全 + 文件整体加锁 + 使用后尽快释放。这个方案最适合你仍然依赖tmpfile()自动清理功能、又不想改动太多业务代码的场景，算是一个相对轻量的加固手段。

3.4 方案四：文件锁定与权限收敛的组合拳

如果问我哪种方案最适合生产环境，我会推荐方案一（自定义目录）和方案四（锁定+权限收敛）配合使用。单纯依赖一个方面难免有疏漏，组合拳才能把风险降到最低。

权限收敛的含义是：PHP进程运行在一个专用用户下，该用户对临时文件目录拥有权限，其他用户一律无法进入目录。在Linux系统中，设置目录为700权限后，目录的属主（OWNER）才能进入和操作，其他用户（OTHERS）连列目录的权限都没有。这样一来，攻击者即使知道文件名，也无法对目录里的文件做任何操作。

文件锁定的含义是：在同一个PHP进程内，对临时文件句柄添加排他锁，防止其他进程（包括攻击者）在读取期间修改文件。这里需要注意，flock()锁是劝告锁（advisory lock），不是强制锁，如果攻击者的代码不遵守flock()规则，锁是拦不住它的。但对于通过符号链接等方式替换文件的攻击者来说，锁的存在会导致其替换操作对应到一个已经打开的文件描述符上，替换路径并不会影响已经打开的句柄。

组合使用的好处还在于能覆盖不同类型的攻击方式：

这个表格是我做了一个攻击矩阵后总结出来的，可以看到组合方案覆盖面最广。但需要提醒的是，任何方案都无法做到绝对安全，只能做到相对安全。即便采用了最严密的方案，也要定期审计代码逻辑，确保没有引入新的风险点。

4. 常见问题排查与经验总结

4.1 常见问题速查表

在实际排查和修复这个漏洞的过程中，我整理了几个高频率出现的问题，方便各位对照检查：

4.2 我的实操心得

这些坑我自己都踩过，这里写几个比较有代表性的心得。

第一，不要迷信tmpfile()的随机文件名。早期版本的PHP使用rand()或者mt_rand()来生成临时文件名，这两个函数生成的随机数格强度不够，在有足够样本的情况下可以预测。后来PHP改用random_bytes()生成16字节随机数，安全性大幅提升，但你无法保证使用了旧版本PHP的服务器都被升级了。站在安全加固的立场上，不能依赖一个你无法控制的函数来保证安全。

第二，实际项目中，光看PHP代码是看不出竞争条件风险的，要和部署环境一起看。同一个业务代码，放在默认配置的共享虚拟主机（/tmp权限宽松）和放在容器中（临时目录独立、权限受限）里，风险完全不同。写代码的时候要考虑最差的运行环境，而不是假设自己的服务器配置完美。

第三，反序列化和临时文件结合的场景特别危险。如果你在处理临时文件时调用了unserialize()，务必先对文件内容做格式校验，甚至可以考虑用allowed_classes参数限制反序列化可用的类：

php复制<?php
$data = unserialize($content, ['allowed_classes' => false]);

这条配置能把大量的对象注入攻击拦在门外。对于临时文件来说，最简单的反序列化防御策略就是不允许实例化任何类，只解析基本数据类型。如果业务确实需要反序列化为对象，那就得对允许的类做白名单，而不是黑名单。

第四，日志审计不能少。在临时文件创建、内容写入、内容读取、删除这几个环节，尽量打上一层donanım级别的日志，至少记录时长和操作结果。事后排查的时候，这些日志能帮你判断攻击尝试的时间和路径。我见过太多的安全事件因为没有日志，最终只能靠猜判断攻击路径，排查效率极低。

第五，一个容易被忽略的细节：tmpfile()会在脚本结束时自动清理文件，但如果在清理之前发生了异常，文件句柄没有被关闭，临时文件就会残留在/tmp目录下。多次异常后会累积大量残留文件，这些残留文件本身会成为新的攻击面，因为文件名可能被预测，内容可能被篡改。所以，哪怕采用了tmpfile()，也建议加上异常处理逻辑，在finally块中主动关闭句柄：

php复制<?php
$tmp = null;
try {
    $tmp = tmpfile();
    // 业务逻辑
} finally {
    if (is_resource($tmp)) {
        fclose($tmp);
    }
}

这一招虽然简单，但能同时解决句柄泄漏和文件残留两个问题。

按照我个人经验，如果你的项目正在使用tmpfile()，第一优先级的动作是立即按方案一把临时文件迁移到自定义的受控目录中，这一步能消除大半风险。迁移完成后，再逐步加上文件锁定和内容校验，把防御层级做深。最后，在代码评审规范里增加一条硬约束：新的代码不允许直接使用tmpfile()，必须走统一封装的安全临时文件工具类。这样就能在制度层面防止漏洞反复出现。