session加固应从严格模式、仅cookie传递、https cookie和会话生命周期入手。它能减少会话固定与标识泄露风险，但不能修复php2shell的运行时内存问题，也不能替代csrf防护。
先确认会话的启动方是应用还是框架
排查项目统一入口、框架会话中间件、自定义保存处理器，找到会话首次启动的位置。所有相关配置必须在会话启动前生效，不能等页面已经输出内容、会话已经创建完成，再回头补设Cookie参数。
框架通常有自己的配置入口，应优先按框架文档设置并核对最终响应。不要在多个插件里重复启动会话，或让不同模块使用相互冲突的Cookie名称、路径和存储策略。
严格模式与Cookie属性解决的是不同层级的问题
会话标识的作用，是让浏览器关联服务端存储的状态。开启严格模式后，系统会直接拒绝未初始化的客户端会话标识，前提是自定义保存处理器要配套支持对应校验；而限制会话标识仅通过Cookie传递，能降低标识出现在URL或其他传播路径的概率，这两项控制本身就不属于同一层级。
Secure属性限制Cookie仅在安全连接下发送，HttpOnly禁止脚本通过Cookie接口读取会话标识，SameSite则约束部分跨站发送场景。但这几个属性没法完全堵死所有XSS、CSRF风险，业务鉴权、CSRF令牌校验、运行时安全更新都要单独做好配套。
按部署环境完成配置，再核验真实响应结果
先确认外部访问全走HTTPS，代理回源、应用识别协议的逻辑都正确。不要靠信任任意客户端转发的请求头来判断当前是不是安全连接，也别为了测试省事，就在公网环境长期关掉Secure属性。
到启动配置或者框架配置里，开启严格模式、仅Cookie传递，以及需要的其他Cookie属性，结合实际业务选好SameSite策略，别没必要地把Domain和路径范围设得过大。
到测试站点新建会话，查看浏览器网络面板里的Set-Cookie响应头，以及后续请求的实际携带行为。测试要针对新生成的Cookie，别只看浏览器之前存的旧记录，也不能直接把命令行配置结果当成网页端的验收依据。
; HTTPS站点的启动配置示例，按框架和实际业务核对 session.use_strict_mode = 1 session.use_only_cookies = 1 session.cookie_secure = 1 session.cookie_httponly = 1 session.cookie_samesite = Lax session.cookie_lifetime = 0
| 业务情况 | SameSite选择方向 | 需要验证 |
|---|---|---|
| 一般网站与外部链接访问 | Lax作为常见起点 | 登录状态与跨站返回流程 |
| 高隔离的内部后台 | 评估Strict | 外部跳转是否需要重新登录 |
跨站嵌入、单点登录，以及浏览器从支付平台跳转回站点的场景，都要按实际请求方式逐项测试，不能只照抄参数表。SameSite策略不是配一次就永远不变的结论，更不能为解决登录异常直接放开所有Cookie限制。
独立应用的最小启动示例
下面的脚本会在输出内容前先设好参数、启动会话，之后关闭写入操作。它不带任何登录逻辑，也不会把会话标识输出到页面或日志里，适合先用来验证当前运行环境能不能正常接受这些配置。
<?php
// 在session_start和任何输出之前配置；只用于隔离测试。
if (session_status() !== PHP_SESSION_NONE) {
throw new RuntimeException('Configure the session before it starts.');
}
ini_set('session.use_strict_mode','1');
ini_set('session.use_only_cookies','1');
session_set_cookie_params([
'lifetime'=>0, 'path'=>'/', 'secure'=>true,
'httponly'=>true, 'samesite'=>'Lax'
]);
if (!session_start()) { throw new RuntimeException('Session start failed.'); }
$report=['php'=>PHP_VERSION, 'sapi'=>PHP_SAPI,
'strict_mode'=>ini_get('session.use_strict_mode'),
'only_cookies'=>ini_get('session.use_only_cookies'),
'cookie_params'=>session_get_cookie_params(),
'session_started'=>session_status()===PHP_SESSION_ACTIVE,
'note'=>'runtime demonstration; verify actual HTTPS Set-Cookie separately'];
session_write_close(); // 不输出会话标识，不执行登录或身份认证。
echo json_encode($report,JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES),PHP_EOL;
保存为audit.php后执行下列命令。示例在macOS的PHP 8.5.10 WebAssembly环境运行，截图是参数和会话状态的真实输出，不表示目标浏览器已经通过HTTPS Cookie验收。
php audit.php
官方的Cookie参数接口要求必须在会话启动前调用，而且配置效果仅对当前脚本请求生效。把这套示例用到框架项目里的时候，要先确认框架不会提前自动启动会话，所有配置统一放在入口处设置，别在各个业务页面里到处重复粘贴。
别忽略登录后的标识更新和存储权限
登录成功或者用户权限提升时，按框架的安全流程更新会话标识，同时做好旧标识和并发请求的兼容迁移。别简单粗暴地在每个请求里都重新生成标识，也不能忽略网络延迟导致的新旧请求交错问题。
会话存储目录不能给其他普通账号开放权限，敏感页面还要做好防护，避免共享缓存泄露会话信息。业务层要主动显式校验会话的空闲时长和绝对有效期，不能只靠概率触发的垃圾回收机制来判断会话是否失效。
碰到会话异常，先排查四类常见原因
- 参数配置后不生效：检查会话是不是已经提前启动、框架配置有没有覆盖自定义设置，再核对实际Web运行环境。
- 开启Secure后登录态无法保持：确认整条访问链路都走HTTPS，别把本地HTTP测试出的故障，当成生产配置无效。
- 跨站跳转后会话丢失：核对请求方式、SameSite策略和业务校验流程，别上来就直接取消所有限制。
- 旧标识仍可正常使用：逐一审查自定义保存处理器、标识轮换和注销失效逻辑。
PHP2Shell的部分会话上传进度路径可能早于普通会话初始化，而且不要求业务主动启动会话。Cookie属性和严格模式因此不能视为该漏洞的完整缓解措施；仍需核对补丁和工作进程更新。
