LikeShop 安全加固清单：后台权限、接口鉴权与支付回调防护

一、前言在之前的系列文章中我写了 LikeShop 多商户版的部署配置、秒杀性能优化和数据迁移上线流程。这一篇把视角转向安全——多商户系统的安全加固比单商户更复杂因为它多了一层商户维度的数据隔离。多商户系统在工程层面本质上是一个多租户系统需要在一套系统中承载多个相互隔离但共享基础能力的业务单元面临的挑战包括商户数据严格隔离、商品/订单/支付等能力共享。一旦隔离机制出现漏洞A 商户可能看到 B 商户的订单数据这是最致命的业务风险。这篇文章从后台权限、接口鉴权、支付回调防护、数据隔离四个层面给出一份可直接落地的安全加固清单。二、后台权限加固2.1 RBAC 权限模型LikeShop 的权限控制体系基于经典的RBAC基于角色的访问控制模型设计通过用户-角色-权限的三层关联结构实现权限管理。核心逻辑是先创建角色并分配权限再创建管理员账号并绑定角色。不同角色拥有不同的菜单访问权限和操作权限。后台支持按角色分配权限可以给财务、跟单、仓管、运营等不同岗位配置不同的操作权限。2.2 多商户版的权限分层多商户版的权限模型比单商户版多了一个层级平台 → 商户 → 子账号。平台端拥有最高权限可以管理所有商户、审核入驻申请、配置平台抽佣比例商户端只能管理自己店铺的商品、订单、结算等数据子账号商户可以创建多个子账号按角色分配不同权限2.3 加固要点第一权限校验必须在服务端强制执行。前端隐藏菜单按钮只是“体验优化”不是安全措施。所有管理后台的接口必须通过AuthMiddleware进行权限校验。二开时新增的管理接口务必确认已注册到权限节点中。第二低权限账号不能越权操作高权限功能。官方已明确管理后台、商家权限做角色分级接口增加路由权限校验防止低权限账号越权操作高权限功能。二开时新增的接口要明确归属到对应的权限节点。第三定期审计角色权限。检查是否存在权限过大的角色比如普通运营账号拥有财务提现权限及时收敛。三、接口鉴权加固3.1 Token 鉴权机制LikeShop 的接口鉴权基于Token实现。所有需要登录的接口必须在 Header 中携带token参数参数名类型说明tokenstring验证令牌所有需要登录的接口必填versionstring客户端版本所有接口都需要传token 值必须放在 Headers 中不能放在请求参数里。Token 的生成和管理由UserTokenService负责UserTokenService.php中的$userSession-token create_token($userId)负责创建 token 记录。管理后台的 token 过期时长配置在server/config/project.php的admin_token中默认 8 小时。3.2 接口响应中的鉴权信号LikeShop 的接口返回值中code字段有明确的鉴权含义code 值含义1操作成功0操作失败-1需要重新登录token 失效2打开新页面前端请求封装层捕获到code: -1后会自动清除本地 token 并跳转登录页。3.3 加固要点第一生产环境必须使用 HTTPS。Token 在 HTTP 明文传输时容易被中间人截获。LikeShop 支持 HTTP 和 HTTPS但生产环境建议强制使用 HTTPS。注意使用 HTTPS 时如果 SSL 证书不被支付宝认可可能导致支付回调失败。第二合理设置 token 过期时长。管理后台的 token 默认 8 小时过期商城用户的 token 过期时长在project.php中配置。过期时间过长会增加 token 泄露的风险过短会影响用户体验。第三接口参数必须严格校验。新增接口时参数校验要覆盖类型、长度、格式和边界值。LikeShop 的Validate层提供了统一的验证器机制所有输入参数都应经过验证。四、支付回调防护支付回调是安全攻击最集中的环节——伪造回调可实现“0元下单”重复回调可能导致订单被重复处理。4.1 多商户版的回调地址LikeShop 多商户版的支付宝回调地址是域名/api/pay/aliNotify对应文件是server/app/api/controller/Pay.php。注意这个地址和单商户基础版的域名/api/payment/aliNotify不同配置支付时务必确认版本对应的地址。4.2 四层防护机制第一层签名校验。微信、支付宝等回调接口会严格校验签名、订单编号、金额和渠道信息杜绝伪造回调。微信支付 API V3 的回调验签遵循标准流程获取平台证书 → 构造验签名串 → 获取应答签名 → 验证签名。第二层金额校验。验签通过只代表请求来自微信不代表金额正确。回调报文中的金额必须与订单金额比对防止篡改。第三层幂等控制。微信支付的回调机制是“至少一次”投递如果商户服务器没有及时返回 SUCCESS微信会在短时间内多次重试。幂等处理依赖唯一订单号 状态校验根据回调报文中的out_trade_no查询订单如果订单已经是“已支付”状态直接返回 SUCCESS不再重复执行后续逻辑。第四层状态机校验。订单状态变更必须经过状态机的合法性校验。LikeShop 把订单建模为有限状态机核心迁移路径为 CREATED → PAYING → PAID → DELIVERING → FINISHED。状态变更必须具备原子性——更新订单状态和扣减库存在同一事务中完成。4.3 加固要点第一回调地址必须使用 HTTPS。如果 SSL 证书不被支付宝认可会导致回调失败。第二回调接口要限制访问来源。虽然验签是第一道防线但可以在 Nginx 层额外限制回调接口的请求来源 IP微信/支付宝的服务器 IP 段减少恶意请求对系统的冲击。第三回调日志必须完整记录。每次回调的原始报文、验签结果、处理结果都要记录日志方便排查“用户说支付了但订单没变”的问题。五、数据隔离与防越权5.1 水平越权防护水平越权是指用户 A 通过篡改请求参数比如把订单 ID 改成用户 B 的订单 ID查看或操作他人数据。官方已明确修复订单、售后、分销、会员数据均增加数据归属校验用户仅能操作、查看自身相关数据彻底解决水平越权。LikeShop 的做法是在 Logic 层增加归属校验。比如查询订单详情时不仅要根据order_id查询还要加上user_id 当前登录用户的条件。5.2 商户数据隔离多商户版的数据隔离是多租户架构的核心。商户数据必须严格隔离防止越权访问。LikeShop 的订单、售后、分销、会员数据均增加了数据归属校验。商家端的查询接口会自动加上shop_id过滤条件确保商家只能看到自己的数据。5.3 加固要点第一所有查询必须带归属条件。二开时新增的查询接口必须显式加上数据归属条件。不要依赖“前端传的 user_id 是可信的”这种假设。第二避免直接使用前端传入的 ID 做查询。比如查询订单时应该用where(id, $id)-where(user_id, $this-userId)而不是find($id)。第三商户维度的接口要校验 shop_id。商家后台的接口必须校验当前登录商家是否有权操作目标数据。六、部署层面的安全加固6.1 必须关闭调试模式生产环境的server/.env文件中APP_DEBUG必须设为false。调试模式开启时会暴露详细的错误堆栈包含数据库连接信息、文件路径等敏感内容。6.2 修改后台默认访问路径官方建议修改后台默认访问地址避免被暴力破解。默认的/admin/login路径是攻击者最先尝试的目标可以通过 Nginx 配置一个自定义路径。6.3 禁用弱密码和开启登录保护官方建议禁用弱密码开启登录验证码、异地登录校验。这些功能在管理后台的安全设置中配置。6.4 限制敏感目录访问在 Nginx 配置中禁止访问敏感文件和目录location ~ ^/(\.env|\.git|runtime|install) { deny all; }6.5 定期备份和更新定期备份数据库限制服务器目录权限避免误操作或攻击导致数据丢失。同时保持 LikeShop 版本更新——历史漏洞均集中在 v2.5.7 及更早的停止维护版本当前最新版本已彻底修复。七、安全加固检查清单检查项配置位置优先级生产环境关闭 APP_DEBUGserver/.env高强制使用 HTTPSNginx 配置高回调接口验签开启Pay.php/PayController.php高订单数据归属校验Logic 层高商户数据隔离校验Logic 层高接口权限节点注册AuthMiddleware高修改后台默认路径Nginx 配置中禁用弱密码管理后台安全设置中开启登录验证码管理后台安全设置中定期数据库备份宝塔计划任务中限制敏感目录访问Nginx 配置中定期更新 LikeShop 版本官方仓库中八、总结LikeShop 多商户版的安全加固核心可以概括为四条线后台权限基于 RBAC 模型平台 → 商户 → 子账号三层权限分层所有接口必须经过服务端权限校验。接口鉴权Token 放在 Header 中传递code: -1表示需要重新登录生产环境强制 HTTPS。支付回调防护签名校验 → 金额校验 → 幂等控制 → 状态机校验四层机制缺一不可。多商户版的回调地址是域名/api/pay/aliNotify。数据隔离所有查询必须带归属条件商户维度的接口必须校验shop_id杜绝水平越权和跨商户数据泄露。安全加固不是一次性的工作而是持续的过程。建议把上面的检查清单保存下来每次二开新增功能或上线前逐项核对。本文基于 LikeShop 多商户版 源码及官方安全公告整理不同版本的代码路径和配置方式可能略有差异请以实际源码为准。