17370845950

订单日志防篡改需哈希链+只追加存储+事务内固化关键字段+独立签名校验：每条日志含前一条哈希，用HMAC-SHA256签名；日志写入权限受限的只追加存储；关键字段在订单状态变更事务中从DB快照获取并编码；校验由root运行的独立CLI脚本完成，时间戳须来自可信源。

订单日志一旦被篡改，就失去了审计价值——PHP 本身不提供日志防篡改能力，必须靠外部机制+设计约束共同实现。

用不可逆哈希链串联日志条目

单条日志加签名只能防单条篡改，但攻击者可删掉中间几条再重算后续签名。更可靠的做法是让每条日志包含前一条的 sha256 哈希值，形成链式结构。

• 写入新日志前，先查最新一条的 prev_hash 字段（或从文件末尾读取上一条哈希）
• 将当前日志内容（含时间、订单ID、操作、用户ID等关键字段）拼接后计算 hash_hmac('sha256', $content, $secret_key)，作为本条的 curr_hash
• 把 prev_hash（上一条的 curr_hash）和 curr_hash 一起存入数据库或追加到日志文件
• 验证时只需从头开始逐条校验哈希是否匹配，任意中断即说明被删改

把日志写入只追加且权限受限的存储

文件系统层面比应用层更早拦截篡改行为。不要用普通 fopen(..., 'a') 写日志，而应：

• 将日志目录归属设为独立系统用户（如 logwriter），Web 进程（如 www-data）仅对其有 write 权限，无 read 或 delete 权限
• 使用 openlog() + syslog() 将日志发给 rsyslog，配置其按订单ID归档并启用 $ActionFileEnableSync on 确保落盘
• 若必须写文件，用 fopen($path, 'c') + flock($fp, LOCK_EX) 避免并发覆盖，且文件创建后立即 chmod 400

关键字段必须在日志生成时固化，禁止运行时补全

很多“防篡改”失效，是因为日志里写了 user_id: $_SESSION['uid'] 这类动态引用——攻击者只要劫持会话就能伪造。真正安全的日志要：

立即学习“PHP免费学习笔记（深入）”；

• 在订单状态变更的**同一事务内**，把当时有效的上下文快照写入日志：比如 order_status_change 操作发生时，立刻记录 old_status、new_status、operator_ip、operator_uid（从 DB 查出，非 session）、audit_timestamp（用 microtime(true) 而非 date()）
• 所有字段值在写入前做 json_encode() 并 base64 编码，避免日志解析器误切分特殊字符
• 禁用日志中任何可执行逻辑，例如不写 eval()、不拼接变量进 SQL 日志语句

用独立服务做日志签名校验与归档

PHP 进程无法保证自身可信，所以签名密钥和校验逻辑不能和业务代码共存。推荐拆出一个轻量 CLI 脚本，每天定时执行：

#!/usr/bin/env php
tamp'] . '|' . $data['order_id'] . '|' . $data['action'];
    $expected = hash_hmac('sha256', $content, $key);
    if ($data['curr_hash'] !== $expected) {
        echo "ALERT: Hash mismatch for order {$data['order_id']}\n";
        exit(1);
    }
    $prev_hash = $data['curr_hash'];
}
echo "OK: All logs verified.\n";

这个脚本由 root 定时运行，输出直接写入隔离的审计日志，且其二进制、密钥、日志路径全部不可被 Web 用户访问。

最易被忽略的一点：时间戳必须来自可信源（如数据库 NOW(6) 或 NTP 同步服务器），不能依赖 PHP 的 time() —— 攻击者一旦拿下服务器，第一件事就是调快系统时间来绕过基于时间的签名有效期校验。