webman本身不提供自动参数签名或防篡改机制，所有请求参数默认可被任意修改，必须通过自定义中间件（如signverify.php）实现sign校验：按key字典序拼接非sign/timestamp参数+密钥，用hash_hmac('sha256')生成并比对签名，同时校验timestamp时效性（如±300秒），且须配合服务端权限与业务逻辑二次校验。
Webman本身不提供自动的Request参数签名或防篡改机制，所有请求参数默认可被任意修改。你必须自己在业务逻辑层加验签、加白名单、加中间件校验，否则攻击者能轻易伪造ID、金额、状态等关键字段。
Webman中如何识别被篡改的Request参数
参数篡改通常表现为：前端传来的id、status、price等字段值明显异常（如id=9999999999超出业务范围），或同一接口多次请求时token、timestamp、sign组合不一致。Webman的$request->all()拿到的是原始未校验数据，没有任何防护逻辑内置其中。
常见错误现象：
- 用户通过浏览器开发者工具修改表单
amount字段，绕过价格校验完成支付 - URL中手动拼接
?user_id=123访问他人数据，后端未做权限绑定校验 - API返回的
data.sign未被验证，导致响应体被中间人篡改后前端仍信任执行
给Webman添加参数签名验证中间件
签名验证是防篡改最直接有效的手段，适用于API接口。核心思路是：客户端用约定密钥+参数+时间戳生成sign，服务端复现计算并比对。
实操建议：
- 在
app/middleware/下新建SignVerify.php，注册到全局或路由组中间件中 - 只对
GET和POST参数参与签名，排除sign、timestamp本身；按key字典序排序后拼接 - 强制校验
timestamp有效期（如±5分钟），防止重放攻击 - 使用
hash_hmac('sha256', $str, $secret)而非md5()，避免碰撞风险
示例片段（仅示意逻辑）：
public function process($request, \Closure $next)
{
$params = $request->all();
$sign = $params['sign'] ?? '';
$timestamp = (int)($params['timestamp'] ?? 0);
if (abs(time() - $timestamp) > 300) {
throw new \Exception('Invalid timestamp');
}
unset($params['sign'], $params['timestamp']);
ksort($params);
$str = http_build_query($params) . '&key=' . config('app.sign_key');
$expected = hash_hmac('sha256', $str, config('app.sign_key'));
if (!hash_equals($expected, $sign)) {
throw new \Exception('Sign verification failed');
}
return $next($request);
}
为什么不能只靠Webman的$request->get()或input()方法
这些方法只是语法糖，本质仍是读取$_GET、$_POST或php://input原始数据，不做任何完整性或合法性判断。它们无法区分“用户正常提交”和“抓包后手工修改”的参数。
容易踩的坑：
- 误以为
$request->integer('id')能防篡改——它只做类型转换，id=abc会转成0，但id=1234567890依然畅通无阻 - 在控制器里用
in_array($status, ['pending','paid'])做白名单，却没校验该$status是否来自当前用户可操作的订单 - 把签名密钥硬编码在中间件里，或写进
config/app.php明文暴露
配合数据库查询做二次校验才是闭环
签名只能保证“参数没被中途篡改”，不能替代业务层权限控制。比如一个order_id即使签名正确，也必须查库确认该订单归属当前登录用户。
实操要点：
- 所有涉及用户私有资源的操作（如查看订单、修改地址），先用
Auth::id()或session('user_id')取出当前身份，再作为WHERE条件之一查询 - 避免“先查订单，再判断用户ID是否匹配”的两步走，应合并为单条SQL：
SELECT * FROM orders WHERE id = ? AND user_id = ? - 对敏感字段（如
price、discount）不在前端传入，而是在服务端根据商品ID查库获取真实值
真正难的不是加一层sign，而是每处业务都得想清楚：“这个参数谁有权改？改了之后会不会越权？有没有服务端兜底校验？”——这些逻辑Webman不会替你写，也永远不该由框架代劳。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
