1. 从一只虾到一条链爆火背后被忽视的攻击面小龙虾这个品类在过去两年里经历了一轮罕见的爆发式增长。从街边大排档到连锁品牌从线下堂食到预制菜电商整条产业链在极短时间内完成了数字化改造。点单小程序、会员系统、供应链管理平台、直播带货后台、外卖聚合接单系统——这些工具在半年内被仓促塞进了原本只靠一部电话和一本手写账本就能运转的生意里。我之所以关注这个话题是因为身边好几个做餐饮SaaS的朋友都在聊同一件事客户催着上线安全评审基本为零。一个典型的场景是某连锁品牌为了赶在旺季前上线会员储值功能从立项到上线只用了十一天。十一天里前端调通了支付接上了数据库建好了但没有人问过一句这个系统的接口有没有做频率限制用户手机号在数据库里是明文还是加密后台管理页面的登录态是怎么维持的这不是个别现象。当一个行业突然涌入大量热钱和流量时技术团队的第一优先级永远是能不能跑起来而不是跑起来之后会不会被人从后面踹一脚。小龙虾产业的数字化恰恰处在这个阶段——业务跑得比安全快而攻击者最喜欢的就是这种时间差。这篇文章想聊的不是某个具体漏洞的利用教程而是从从业者视角出发把这类爆火行业数字化中反复出现的几类安全问题拆开来看。我会讲清楚每一类问题的成因、攻击者通常从哪个角度切入、以及在实际项目中可以怎么低成本地堵住这些口子。适合正在做餐饮/零售类系统的开发者、刚接手这类项目的技术负责人以及对业务安全感兴趣的读者参考。2. 点单小程序里的数据暴露从手机号到储值余额2.1 为什么这类系统天生容易泄露数据餐饮类小程序的开发节奏和传统企业软件完全不同。传统企业软件有明确的需求文档、测试周期和上线评审而餐饮小程序往往是老板今天说要加个功能明天就要看到效果。这种节奏下开发者的注意力全部集中在功能实现上数据安全往往被默认成框架会帮我处理。但框架不会帮你处理业务层面的数据暴露。举个最常见的例子用户在小程序里查看自己的订单详情前端发起一个请求后端返回一个包含订单信息的JSON。如果这个接口的设计是传入订单ID返回订单详情而没有校验这个订单ID是否属于当前登录用户那么任何人只要把订单ID改一个数字就能看到别人的订单——包括姓名、手机号、配送地址、消费金额。这类问题在安全圈里叫越权访问分为水平越权和垂直越权两种。水平越权是同级用户之间的数据互访比如A用户能看到B用户的订单垂直越权是低权限用户访问高权限功能比如普通用户能进管理后台。餐饮类系统里水平越权是最常见的因为订单查询、会员信息查询、优惠券领取这些功能天然就是按ID取数据的模式。2.2 一个真实的排查思路假设你接手了一个已经上线的点单系统想快速判断它有没有越权问题可以按下面的顺序过一遍列出所有传入ID返回数据的接口。打开浏览器的开发者工具在小程序里把每个页面都点一遍记录下所有请求URL和参数。重点关注包含id、orderId、userId、memberId这类参数的接口。用两个账号做交叉测试。注册两个普通账号分别下单然后用账号A的登录态去请求账号B的订单ID。如果返回了数据说明存在水平越权。检查返回字段。即使接口做了归属校验也要看返回的字段里有没有多余信息。比如订单详情接口返回了用户的完整手机号但前端只展示了后四位——那这个完整手机号就是多余的暴露面。检查批量接口。有些系统为了减少请求次数会提供批量查询接口比如传入一个ID数组返回多条数据。这类接口如果没做逐条归属校验危害比单条查询更大。注意做这类测试时务必使用自己注册的测试账号不要尝试访问真实用户的数据。未经授权的测试可能触犯法律。2.3 修复方案与成本评估越权问题的修复其实不复杂核心原则就一条每一个数据查询都必须带上当前登录用户的身份条件。具体到代码层面就是把WHERE id ?改成WHERE id ? AND user_id ?。如果用的是ORM框架就是在查询条件里强制附加当前用户的ID。但实际项目中这个修复往往会遇到阻力。原因在于有些接口在设计之初就没有考虑用户维度比如根据订单号查询订单这个功能可能是给客服用的客服需要能查任何订单。这种情况下正确的做法是把接口拆成两个面向用户的接口强制带用户ID面向客服的接口走独立的权限校验。成本方面一个中等规模的餐饮小程序大概有30到50个接口其中涉及数据查询的可能有20个左右。如果代码结构清晰一个熟练的开发者大概需要两到三天完成排查和修复。如果代码是外包做的、结构混乱时间可能要翻倍。但相比数据泄露后的公关成本和监管处罚这个投入是值得的。3. 储值余额与优惠券黑产眼中的高价值目标3.1 为什么储值功能是重灾区小龙虾品类的客单价不低很多品牌会推储值优惠来锁定复购。比如充500送100用户账户里就有了600元的余额。这个余额在系统里就是一个数字字段而这个数字字段的读写逻辑往往就是黑产重点关照的对象。我见过最离谱的一个案例是某品牌的储值系统在充值回调接口里没有做签名校验。也就是说支付平台通知用户充值成功的那个请求任何人都可以伪造。攻击者只需要构造一个包含用户ID和充值金额的请求发给服务器账户余额就直接加上去了。这个漏洞从上线到被发现中间隔了将近两个月损失的具体金额没有对外公布但据说足够让技术负责人直接走人。即使做了签名校验还有一类问题叫并发竞争。比如用户账户里有100元余额同时发起两笔80元的消费请求。如果系统在处理时是先读余额、判断够不够、再扣减那么两个请求可能同时读到100元都判断为够然后各自扣减80元最终余额变成-60元。这就是典型的竞态条件漏洞。3.2 支付回调的安全设计要点支付回调是储值系统的命门设计时至少要满足以下几点签名验证支付平台的回调请求必须携带签名服务端要用约定的密钥验证签名。签名不通过的请求直接丢弃不要返回任何业务信息。金额校验回调里的金额必须和订单创建时的金额一致。有些系统只校验订单号不校验金额攻击者可以把1元充值的回调改成1000元。幂等处理同一个回调可能被重复发送系统必须保证同一笔订单只处理一次。通常的做法是在数据库里记录已处理的回调ID处理前先查重。异步确认不要依赖前端跳转结果来判定支付成功必须以服务端收到的回调为准。前端跳转可以被伪造服务端回调相对可靠。3.3 优惠券系统的常见逻辑漏洞优惠券的问题通常不在技术层面而在业务逻辑层面。比如无限领取领券接口没有做频率限制也没有校验用户是否已领过。攻击者写个脚本就能把一批券全部领走。叠加使用系统允许同一订单使用多张优惠券但没有限制叠加规则。攻击者通过组合不同券种可以把订单金额压到极低甚至负数。过期券复用券过期后状态没有及时更新或者更新了但核销接口没有校验状态导致过期券仍可使用。退款不退券用户用券下单后申请退款系统退了钱但没有收回优惠券用户相当于白赚一张券。这些问题的共同点是它们不是代码写错了而是业务规则没有想清楚。修复方式通常是在关键操作上加校验、加限制、加日志。比如领券接口加用户维度的频率限制核销接口加券状态和有效期的双重校验退款流程里加券的回收逻辑。4. 供应链与后台系统被低估的入口4.1 后台管理页面的弱口令问题前台小程序的安全做得再好如果后台管理页面用的是admin/123456那一切努力都白费。餐饮行业的后台系统有个特点使用者往往是不懂技术的店长或运营人员他们倾向于设置简单好记的密码而且多个系统共用同一个密码。更麻烦的是很多后台系统的登录页面直接暴露在公网上没有做IP白名单也没有做登录失败锁定。攻击者可以用自动化工具对后台登录接口进行撞库成功率远比想象中高。我建议的做法是后台系统尽量不直接暴露在公网通过内网访问或加一层访问控制。强制密码复杂度至少8位包含大小写字母和数字。登录失败5次后锁定账户15分钟或者引入图形验证码。对后台的所有操作记录审计日志包括登录、查询、修改、导出。4.2 供应链数据的敏感性小龙虾供应链涉及采购价格、供应商信息、库存数量、物流轨迹等数据。这些数据在竞争激烈的餐饮行业里属于核心商业机密。如果被竞争对手拿到可以直接推算出你的成本结构和采购渠道。供应链系统的安全重点和前台不同它更关注访问控制和数据脱敏。比如采购价格字段只对采购角色可见运营角色只能看到库存数量。供应商联系方式在非必要场景下脱敏展示。数据导出功能加审批流程防止内部人员批量导出后带走。这些措施听起来简单但在实际项目中往往被忽略因为系统上线时通常只考虑了功能能不能用没有考虑谁能用哪些功能。4.3 第三方接口的信任边界餐饮系统通常会对接多个第三方服务支付、短信、地图、外卖平台、电子发票等。每对接一个第三方就多一个外部入口。如果第三方接口的调用没有做鉴权或者回调地址暴露在外就可能被利用。一个常见的疏忽是短信接口没有做频率限制。攻击者发现你的短信发送接口后可以写脚本疯狂调用导致你的短信费用暴涨同时用户被骚扰。修复方式是在发送短信前加图形验证码并对同一手机号、同一IP做频率限制。另一个疏忽是外卖平台的订单回调没有做来源校验。攻击者可以伪造订单回调在你的系统里生成虚假订单干扰正常运营。修复方式是校验回调请求的签名或来源IP。5. 从应急到常态小团队的安全建设路径5.1 先做资产梳理再谈防护很多小团队一提到安全建设第一反应是买个WAF或者上个堡垒机。但在不知道自己要保护什么的情况下买再多设备也是浪费。第一步应该是资产梳理把所有的域名、服务器、数据库、接口、第三方服务都列出来标注每个资产的重要程度和负责人。资产梳理的产出是一张表大概长这样资产类型具体资产重要程度负责人当前防护措施域名小程序API域名高后端A无服务器生产环境应用服务器高运维B基础防火墙数据库用户数据库高后端A无审计接口支付回调接口高后端A签名校验第三方短信服务中后端C无频率限制这张表不需要很精确但必须要有。有了它你才能判断哪些地方需要优先投入。5.2 用最低成本堵住最大的洞对于资源有限的小团队安全建设应该遵循二八原则用20%的投入解决80%的风险。根据我的经验以下几项是性价比最高的接口鉴权全覆盖确保每一个需要登录才能访问的接口都做了身份校验每一个数据查询都带了用户归属条件。这一项能挡住大部分越权问题。关键操作加日志登录、支付、退款、修改密码、导出数据这些操作必须记录日志包括操作人、时间、IP、操作内容。出问题时日志是唯一的追溯依据。数据库定期备份备份要离线保存并且定期验证可恢复性。很多团队做了备份但从来没恢复过真出事时才发现备份是坏的。依赖组件及时更新框架、中间件、第三方库的已知漏洞是攻击者的首选目标。建立一个简单的依赖清单定期检查更新。5.3 把安全写进开发流程安全问题的根源往往不在技术而在流程。如果每次上线都是先上再说那安全问题永远只能靠事后补救。小团队可以尝试把以下几件事写进开发流程上线前检查清单包括接口鉴权、敏感数据加密、日志记录、错误信息脱敏等。不需要很复杂一页纸就够。代码评审关注安全在代码评审时除了看逻辑对不对也看一眼有没有明显的安全问题比如SQL拼接、硬编码密钥、日志打印敏感信息。定期做一次简单扫描用开源的扫描工具对线上系统做一次基础扫描看看有没有暴露的敏感文件、弱口令、已知漏洞。频率不用很高一个季度一次就行。这些措施不会让你的系统变得绝对安全但能让攻击者的成本显著提高。在安全领域让攻击者觉得不划算往往比追求无懈可击更现实。6. 一个值得反复提醒的细节日志里的敏感信息最后聊一个特别容易被忽略、但危害很大的问题日志泄露。开发者在排查问题时习惯把请求参数和响应内容都打到日志里。这本身没问题问题在于很多系统会把用户的手机号、身份证号、银行卡号、密码明文打进日志。而这些日志往往存储在多个地方应用服务器本地、日志收集系统、监控平台、甚至开发者的本地电脑。一旦这些日志被泄露危害不亚于数据库被拖。而且日志泄露往往更隐蔽因为很多人根本不知道自己的日志里有什么。我的建议是在日志框架里配置脱敏规则对手机号、身份证号、银行卡号等字段自动打码。禁止在日志里打印密码、密钥、Token等凭证信息。日志的访问权限要控制不是所有开发人员都需要看生产日志。日志的保留时间要有策略不需要永久保存的日志定期清理。这些操作不需要太多技术投入但能堵住一个非常隐蔽的泄露渠道。我在实际项目中见过太多数据库加密做得很好但日志里全是明文手机号的情况希望你不要成为下一个。