解决演示库与原数据库会话共享引发的越权访问问题

这确实是个典型的跨环境会话复用漏洞，很容易导致演示环境的会话意外访问生产数据。既然你不能修改$_SESSION["id"]这个键名的所有引用，我给你几个不需要改动这个键的解决方案：

这个方案的核心是给会话打上环境标签，每次请求都验证当前环境与会话标签是否匹配：

• 登录逻辑改造：在演示库登录成功后，除了设置$_SESSION["id"] = 1，额外添加环境标识：

  $_SESSION["env"] = "demo"; // 演示环境标记
  

  在原库登录时则设置：

  $_SESSION["env"] = "production"; // 生产环境标记
  

• 全局拦截验证：在所有需要用户身份的页面/接口的初始化代码最前面，加入验证逻辑：

  // 假设你用常量定义当前环境，比如 define('APP_ENV', 'demo');
  if (isset($_SESSION["env"]) && $_SESSION["env"] !== APP_ENV) {
      // 环境不匹配，销毁会话并强制跳转登录页
      session_destroy();
      header("Location: /login.php");
      exit();
  }
  

• 优势：改动极小，只需要在登录和全局入口加代码，完全不影响现有$_SESSION["id"]的引用，能彻底阻断跨环境会话复用。

这个方案直接让演示库和原库使用完全独立的会话，从根源上避免会话共享：

• 设置不同会话名称：在演示库的全局配置/初始化文件中，启动会话前指定专属会话名称：

  session_name("DEMO_APP_SESSION"); // 演示环境会话名
  session_start();
  

  在原库的初始化文件中则设置：

  session_name("PROD_APP_SESSION"); // 生产环境会话名
  session_start();
  

• 原理：不同的会话名称会对应浏览器中不同的Cookie，演示环境的会话Cookie不会被带到生产环境的请求中，两个环境的会话数据完全隔离，互不访问。
• 优势：几乎零业务代码改动，只需要修改会话启动的配置，是最彻底的解决方案，推荐优先使用。

如果你的演示库和原库是同一应用实例下的不同数据库连接（比如通过URL参数切换环境），可以给会话绑定数据库实例标识：

• 登录时绑定数据库标识：登录成功后，除了$_SESSION["id"]，再存储当前使用的数据库实例：

  // 演示库登录
  $_SESSION["db_instance"] = "demo_db";
  // 原库登录
  $_SESSION["db_instance"] = "prod_db";
  

• 查询前验证上下文：在所有数据库查询的封装方法中，添加前置验证：

  // 假设当前使用的数据库实例为$current_db
  if (isset($_SESSION["db_instance"]) && $_SESSION["db_instance"] !== $current_db) {
      // 上下文不匹配，抛出异常或返回无权限提示
      die("Access denied: Session does not match current database context");
  }
  

• 优势：适合单应用多数据库的场景，能精准控制会话只能在对应的数据库环境下生效，不会影响其他业务逻辑。

内容的提问来源于stack exchange，提问作者Entrepreneur