Ruby生态中的轻量级框架Scorched虽然小众，但其会话插件设计相当精巧。默认情况下，会话数据以Marshal序列化后直接写入Cookie，这意味着用户端可以看到（并篡改）会话中的所有内容。通过启用Scorched::Plugins::Session::Encrypted加密方案，并搭配Serializer::Json序列化器，可以让会话数据在传输前完成加密，读取时自动解密，既保证了机密性，又借助JSON格式获得了更好的兼容性。本文将围绕这套组合的配置方法与底层原理展开。
Scorched会话插件的工作原理
Scorched的会话功能由Scorched::Plugins::Session插件提供，其内部将一个完整的Ruby哈希作为会话容器。当请求结束时，框架会把会话哈希序列化成字符串写入Cookie；下一个请求进来时，再从Cookie中读出字符串，反序列化回哈希。整个生命周期对开发者是透明的，你在控制器里操作session就像操作普通Hash一样。
这套流程中有两个可以替换的组件：一个是序列化器（Serializer），负责Ruby对象与字符串之间的转换；另一个是加密层（Encrypted），负责字符串的加密与解密。默认配置使用Marshal作为序列化器，不启用加密。Marshal虽然能完整保留Ruby对象结构，但它产生的二进制数据不适合放在Cookie中，而且存在反序列化攻击风险——如果密钥泄露，攻击者可以构造恶意Marshal数据执行任意代码。
将序列化器换成JSON后，会话中只能存放可被JSON表达的数据类型：字符串、数字、布尔值、数组、哈希和nil。这个限制实际上是一种约束带来的安全保障，因为即使密钥被破解，攻击者也无法通过JSON注入执行代码。同时JSON格式天然跨语言，如果你后续有其他服务需要读取会话数据，处理起来也方便得多。
配置Encrypted加密与JSON序列化器
启用这套方案需要在应用中同时引入加密模块和JSON序列化模块，并生成一个足够强度的密钥。密钥建议使用SecureRandom生成至少32字节的随机字符串，并将其保存在环境变量或独立的配置文件中，千万不要提交到代码仓库。下面是完整的配置示例：
require 'scorched'
require 'scorched/plugins/session/encrypted'
require 'scorched/plugins/session/serializer/json'
require 'securerandom'
class App < Scorched::Controller
plugin Scorched::Plugins::Session
# 生成一次后固定保存，重启应用不能改变
# 可用命令生成：ruby -rsecurerandom -e "puts SecureRandom.hex(32)"
session_config[:secret] = ENV['SESSION_SECRET']
# 启用加密层
include Scorched::Plugins::Session::Encrypted
# 启用JSON序列化器
include Scorched::Plugins::Session::Serializer::Json
end
class MyApp < App
get '/' do
session[:user_id] = 42
session[:login_at] = Time.now.to_i # 注意：Time对象需转成时间戳
'session已加密写入Cookie'
end
end
run MyApp配置中有几个容易踩坑的点需要特别注意。第一，密钥一旦变更，所有已存在的加密会话将无法解密，用户会被强制登出，因此密钥的稳定性至关重要。第二，JSON序列化器无法直接处理Time、Symbol这类Ruby特有对象，写入前要手动转换：Time转成整数时间戳或ISO8601字符串，Symbol转成字符串。第三，从会话中读出的键永远是字符串类型，写入时用session[:user_id]，读回后就是session['user_id']，混用会导致取值失败。
加密实现细节与算法选择
Encrypted模块底层使用AES-256-GCM认证加密算法，这是目前业界推荐的对称加密方案。GCM模式的优势在于同时提供机密性和完整性校验：每次加密都会生成随机的初始化向量（IV），并附带认证标签（auth tag），解密时若发现数据被篡改，认证校验会直接失败并抛出异常，框架随之将会话视为空会话重新开始，而不是使用被篡改的数据。
你可以简化模拟其核心逻辑来理解流程，下面是一个等价的演示实现：
require 'openssl'
require 'json'
class SessionCipher
def initialize(secret)
# 从密钥派生出32字节加密密钥
@key = Digest::SHA256.digest(secret)
end
def encrypt(hash)
cipher = OpenSSL::Cipher.new('aes-256-gcm')
cipher.encrypt
cipher.key = @key
iv = cipher.random_iv
ciphertext = cipher.update(JSON.generate(hash)) + cipher.final
# 拼接IV、密文与认证标签，Base64编码后适合放入Cookie
Base64.strict_encode64(iv + cipher.auth_tag + ciphertext)
end
def decrypt(blob)
data = Base64.strict_decode64(blob)
decipher = OpenSSL::Cipher.new('aes-256-gcm')
decipher.decrypt
decipher.key = @key
decipher.iv = data[0, 12]
decipher.auth_tag = data[12, 16]
JSON.parse(data[16..-1])
end
end这种实现方式带来的安全收益是明确的：即使攻击者拿到了Cookie内容，没有密钥也无法读取其中的用户信息；即使尝试修改密文中的任意字节，GCM认证标签校验都会失败。相比之下，仅用Base64编码或者明文Marshal的方式，等于把会话内容完全暴露给客户端，用户的ID、角色等信息一目了然，为越权攻击留下了可乘之机。
JSON序列化与Marshal的实际对比
两种序列化器的差异可以从下表直观看出：
| 对比项 | Marshal | Serializer::Json |
|---|---|---|
| 支持的数据类型 | 几乎所有Ruby对象 | 仅JSON原生类型 |
| 安全性 | 存在反序列化代码执行风险 | 数据格式安全，无代码执行可能 |
| 跨语言支持 | 仅Ruby | 任何支持JSON的语言 |
| 可读性（解密后） | 二进制不可读 | 结构清晰可读 |
| Cookie体积 | 较大 | 相对紧凑 |
从工程角度看，JSON序列化器尤其适合微服务或前后端分离的场景。比如你的会话需要在Ruby后台和一个Node.js的网关之间共享，只要两边持有相同的密钥，Node端用crypto模块同样能完成AES-256-GCM解密，再用JSON.parse拿到会话内容。而Marshal数据在Ruby之外完全无法解析，这种锁定效应在多语言团队中会带来实际的维护成本。
总结来说，在Scorched项目中启用Encrypted加JSON序列化的组合，改动成本极低，却同时解决了会话机密性、完整性和反序列化安全三个问题。落地时记住三条原则：密钥用环境变量管理且保持稳定；会话中只存简单数据类型，复杂对象转为字符串或时间戳；键名访问统一使用字符串风格。做到这些，你的会话机制就已经达到了相当高的安全水位。
Scorched框架会话加密JSON序列化修改时间：2026-09-09 15:27:09