PHP框架Session审计需重点检查五项：① strict_mode是否启用，否则存在会话固定；② Cookie是否含HttpOnly和Secure属性，缺失则易遭XSS窃取；③ 是否禁用URL透传SID，否则泄露于历史、日志；④ save_path是否Web不可访问且权限为700，否则会话文件可被下载；⑤ 登录后是否调用session_regenerate_id(true)并销毁旧会话，否则会话固定漏洞成立。
你要审计一个PHP框架的Session机制，不是看它有没有session_start()，而是揪出它默认配置里埋着的会话劫持入口、会话固定温床和Cookie泄漏通道——这些漏洞往往在用户登录后才真正爆发。
确认框架是否启用严格会话模式
打开框架的初始化入口文件（通常是public/index.php或bootstrap/app.php），查找session_start()调用前是否有ini_set('session.use_strict_mode', 1)或等效配置。没有？立刻补上。
检查php.ini或框架配置文件中session.use_strict_mode是否为On。若为Off或未设置，【攻击者可预置合法SID并诱导用户登录，完成会话固定】。
运行php --ini定位生效的php.ini路径，执行grep -i "session.use_strict_mode" /path/to/php.ini；返回空行即表示未启用。
立即学习“PHP免费学习笔记（深入）”；
验证会话Cookie是否具备HttpOnly与Secure属性
方法一：用浏览器开发者工具 → Application → Cookies，查看PHPSESSID条目。若HttpOnly列显示“✓”且Secure列也为“✓”，说明基础防护已生效。
方法二：抓包观察响应头。访问任意含session_start()的页面，用curl -I http://yoursite.com/test.php，确认响应头含Set-Cookie: PHPSESSID=xxx; path=/; HttpOnly; Secure；缺任一标记即存在XSS窃取风险。
方法三：在框架中间件或启动脚本中搜索session_set_cookie_params()调用。若参数中未显式传入true作为第三个（HttpOnly）和第四个（Secure）参数，【默认不开启HttpOnly，JavaScript可直接读取document.cookie盗取SID】。
检查会话ID是否在URL中透传
第一步：在php.ini中确认session.use_trans_sid = Off。若为On，立即改为Off并重启PHP服务。
第二步：检查框架是否主动启用trans_sid逻辑。搜索代码库中是否调用session_id() + URL拼接、是否启用url_rewriter.tags或session.trans_sid_tags配置。哪怕只有一处手动拼接?PHPSESSID=xxx，就会导致会话ID留在浏览器历史、Referer日志和代理缓存中。
第三步：访问一个带查询参数的页面（如/login?next=/profile），查看地址栏是否自动追加了PHPSESSID。出现即代表透传已激活，必须禁用。
审查会话存储路径与权限
执行phpinfo()页面，查找session.save_path值。若路径落在Web可访问目录（如/var/www/html/sessions或/public_html/tmp），【攻击者可直接HTTP请求下载sess_xxx文件，反序列化获取明文账号密码】。
用命令ls -ld $(php -r "echo ini_get('session.save_path');")检查目录权限。返回结果中若包含w（写）权限面向group或其他用户（如drwxrwxr-x），立即执行chmod 700该路径。
确认session.save_handler未设为files以外的高危方式。若为user或自定义handler，需人工审计其write()和read()方法是否做过滤、是否校验SID签名——否则极易被构造恶意序列化数据触发反序列化RCE。
测试登录后是否强制轮换会话ID
① 访问登录页，记录当前PHPSESSID（记为A）；
② 正确提交账号密码完成登录；
③ 立即刷新页面，对比新PHPSESSID是否与A不同。相同则说明未调用session_regenerate_id(true)，【会话固定漏洞成立，攻击者可提前分发含A的登录链接】；
④ 若ID已变更，再检查旧会话文件是否已被删除：在session.save_path下执行ls -t | head -5，确认以原SID命名的sess_开头文件已消失。
