session_start()必须在任何输出前调用，否则触发“headers already sent”错误，导致set-cookie失败、会话标识无法下发，进而使$_session校验失效，为会话伪造创造条件。
session_start() 必须在任何输出之前调用
这是会话伪造最常被绕过的起点。只要 session_start() 前有空格、BOM、echo、HTML 标签，甚至 UTF-8 文件头里的不可见字节，PHP 就会抛出 “headers already sent” 错误——此时 Set-Cookie 失败，浏览器收不到会话标识，后续所有基于 $_SESSION 的校验都形同虚设。攻击者可借此构造无会话上下文的请求，或复用旧 Session ID 发起伪造。
实操建议：
- 用编辑器检查 PHP 文件是否为 UTF-8 无 BOM 编码（尤其 Windows 下 Notepad++ 默认带 BOM）
- 所有会话相关逻辑（包括
session_start()）必须放在<?php开头后第一行，前面不能有任何字符（含空行） - 避免在包含文件中提前输出；若使用模板引擎，确保其不向缓冲区写入任何内容
强制启用 session.cookie_httponly 和 session.cookie_secure
会话伪造常依赖 XSS 窃取 PHPSESSID Cookie。若 Cookie 缺少 HttpOnly 属性，JS 可通过 document.cookie 读取并外传；若未设 Secure，HTTP 明文传输时易被中间人截获重放。
PHP 8.0 中必须显式加固，不能依赖默认值：
- 在
php.ini或运行时设置：session.cookie_httponly = 1、session.cookie_secure = 1 - 若部署在反向代理（如 Nginx）后，需确认代理未覆盖这些头；可用
var_dump(session_get_cookie_params())验证生效情况 -
session.cookie_samesite = Lax也应启用，限制跨站 POST 请求携带 Cookie，降低 CSRF 协同攻击面
启用 session.use_strict_mode 并禁用 session.use_trans_sid
攻击者常通过 URL 拼接 ?PHPSESSID=abc123 强行指定会话 ID，若服务端允许未初始化的 ID 直接复用（即宽松模式），就可能加载他人已存在的会话数据，造成会话劫持。
关键配置项：
-
session.use_strict_mode = 1：拒绝任何未经session_create_id()初始化的会话 ID，强制生成新会话 -
session.use_trans_sid = 0：彻底禁用 URL 传递会话 ID，杜绝PHPSESSID泄露到日志、Referer、代理缓存中 -
session.sid_length = 128（PHP 8.0+ 支持）：增加 SID 长度，提升暴力猜测成本
会话存储路径必须脱离 Web 根目录
默认 session.save_path 指向系统临时目录（如 /tmp），但若被设为 Web 可访问路径（如 /var/www/sessions），攻击者可能直接下载 sess_* 文件，反序列化解析出敏感数据（如用户权限、Token），甚至篡改后重新上传伪造会话。
安全做法：
- 在
php.ini或session_set_save_path()中指定绝对路径，且该路径 不在任何 Web Server DocumentRoot 下 - 确认目录权限为
700，属主为 PHP 运行用户（如www-data），禁止组/其他用户读写 - 生产环境优先使用
redis或database存储驱动，天然规避文件系统暴露风险
真正容易被忽略的是：会话伪造往往不是单点突破，而是和 XSS、CSRF、目录遍历组合发生。比如一个未过滤的用户昵称导致 XSS，再配合 HttpOnly=0 的 Cookie，就能直接盗取 SID；而 use_strict_mode=0 会让这个盗来的 SID 立即生效。每项配置看似独立，实则环环相扣。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
