静态方法与static变量Web端工作机制及多用户平台存储风险问询

运行机制 #

服务端场景 #

• 绝大多数主流Web服务端框架采用多请求共享服务进程的设计，static变量属于类级别全局资源，初始化后会常驻进程内存，生命周期和服务进程一致。所有用户请求都会共享同一个static变量的内存空间，不存在请求/用户维度的隔离。
• 静态方法本身不持有实例状态，仅可访问静态资源，所有请求共用相同的方法调用逻辑，本身无状态，风险完全来自其关联的静态变量存储。

前端场景 #

• 前端JS运行环境中，static变量（或全局作用域下的静态定义变量）的生命周期和当前页面的执行上下文绑定，每个用户的浏览器标签页是独立的执行环境，不会跨用户共享，但页面刷新、关闭后变量会被销毁。

多用户平台存储支付信息到static变量的风险 #

该实现存在极高的安全和业务风险，绝对不可用于生产环境：

• 跨用户数据泄漏：服务端static变量没有用户隔离，A用户写入的支付账号、金额、订单等敏感信息，会被后续所有访问的用户直接读取，出现严重的串号问题，违反数据安全合规要求。
• 并发数据错乱：多用户同时请求时会触发竞态条件，多个请求同时修改静态变量会导致支付数据被覆盖、拼接错误，直接引发资损、订单异常等严重业务问题。
• 敏感数据残留：静态变量不会随单个请求处理结束自动销毁，支付敏感信息会长期残留在服务内存中，攻击者可通过内存dump、漏洞读取等方式窃取数据。
• 即使是前端的静态变量存储支付信息，也存在被XSS攻击读取、用户未关闭页面被他人查看的风险，同样不建议使用。

推荐实现方案 #

• 服务端单用户维度的支付敏感数据，必须和单个请求/用户会话绑定，存储在请求上下文、加密后的用户Session中，随请求结束自动销毁，不得存入任何全局共享的内存空间。
• 需要持久化的支付数据必须加密后存入数据库，严格做用户维度的权限校验。

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