小程序安全如何检查接口

wen 网络安全 1

本文目录导读:

小程序安全如何检查接口

  1. 核心原则:将小程序前端视为“不可信客户端”
  2. 维度一:身份与权限校验(最重要的防线)
  3. 维度二:数据合法性校验(防注入与脏数据)
  4. 维度三:业务逻辑与数据归属校验(用户隔离)
  5. 维度四:防重放与频率控制
  6. 维度五:数据传输安全
  7. 实战检查步骤(如何动手做)
  8. 总结:接口安全的“三把锁”

小程序安全检查接口通常涉及多个层面,核心目的是防止数据泄露、业务逻辑篡改以及未授权访问,由于小程序代码包可被反编译(特别是Android端),前端完全不可信,因此安全重心在后端

以下是针对小程序接口检查的实用清单和最佳实践:

核心原则:将小程序前端视为“不可信客户端”

永远不要在代码中硬编码后端地址外的敏感信息(如数据库密码),建议从以下4个维度检查接口:


身份与权限校验(最重要的防线)

必须检查每一个接口是否验证了用户身份和操作权限,不能依赖前端传参(如 userId: 1001)来区分用户。

  • [必须] Token合法性校验与绑定
    • 检查点:前端每次请求是否都携带了 wx.login() 获取,并通过后端自定义逻辑生成的 session_key / token
    • 安全建议:后端必须验证token的有效性、是否过期,以及token绑定的用户ID是否与操作的数据ID一致。不要直接用微信官方的 session_key 作为业务token,建议用 jwtuuid 生成业务token。
  • [必须] 权限等级划分
    • 检查点:普通用户是否能访问管理员接口(如“删除用户”、“修改商品价格”)?
    • 安全建议:后端接口必须通过注解或中间件进行角色/权限控制。

数据合法性校验(防注入与脏数据)

由于前端可以被绕过,所有数据校验必须后端再做一遍。

  • [必须] 参数校验与类型检查
    • 检查点:是否对接口的 GET/POST 参数进行了长度、类型、枚举值校验?
    • 风险:用户A通过修改请求参数,传入 userId=999999 查看他人订单,后端需要校验“当前登录用户=请求中的用户ID”。
  • [必须] SQL注入与命令注入防护
    • 检查点:所有数据库查询是否使用了参数化查询ORM框架,而非字符串拼接?
    • 风险name=xxx' OR '1'='1 导致数据泄露。
  • [必须] 敏感数据过滤
    • 检查点:返回数据是否包含手机号、身份证号、支付密码等敏感字段?是否进行了脱敏(如 138****1234)?

业务逻辑与数据归属校验(用户隔离)

这是小程序接口最常出问题的点。

  • [必须] 水平越权检查
    • 检查点:用户A是否能通过修改订单ID、商品ID来查看或操作用户B的数据?
    • 测试方法:登录A账号,抓包修改请求中的订单编号(如 /order/detail?orderId=123456),尝试查看用户B的订单信息。
  • [必须] 垂直越权检查
    • 检查点:普通用户能否使用“管理员”或“商家”的接口?
    • 测试方法:小程序前端隐藏了后台按钮,但尝试直接访问后台API地址。
  • [必须] 关键操作幂等性
    • 检查点:重复点击“下单”、“提现”按钮,是否会生成多个订单或重复扣款?
    • 安全建议:后端使用唯一流水号(如订单号)加数据库唯一索引防止重复插入。

防重放与频率控制

  • [必须] 接口防刷与限流
    • 检查点:是否存在未做任何限流的接口?如“发送验证码”、“用户注册”?
    • 风险:短信轰炸、撞库。
    • 安全建议:按用户ID或IP进行单位时间内的请求次数限制(如60秒内只能发1次短信)。

数据传输安全

  • [必须] HTTPS强制
    • 检查点:小程序后台配置的 request 合法域名是否全部为 https://?
    • 风险:http明文传输会在中间人攻击下泄露 token 和通信内容。
  • [建议] 关键数据签名
    • 检查点:对于支付、修改余额等敏感接口,是否进行了参数签名(如HmacSHA256)?
    • 作用:防止请求参数在传输过程中被篡改(如将 price=100 改为 price=1)。

实战检查步骤(如何动手做)

如果你需要检查一个小程序的接口安全,可以按以下流程操作:

  1. 抓包分析:使用抓包工具(如 Charles、Fiddler、Whistle,或手机连接代理 + Proxyman)拦截小程序的所有请求。
    • 看什么:请求是否都有 Authorization 头?Payload 里有没有直接传 user_id
  2. 黑白盒测试
    • 修改参数:拦截下单请求,将 price 改成 01-1,看是否能通过。
    • 修改ID:将订单详情接口中的 orderId 改为另一个已知的订单号,看能否看到别人的地址、手机号。
    • 重复请求:复制下单请求(Repeater),快速重放多次,看是否会生成多个订单。
  3. 代码审计(如有源码)
    • 搜索关键词:搜索 @RequestMapping 或路由配置,看哪些接口没有权限注解。
    • 搜索拼接SQL:搜索 String sql = "SELECT * FROM user WHERE id = " + 这种写法。
    • 搜索敏感日志:搜索 log.info("用户信息: " + user.getPhone()) 是否记录了完整手机号。

接口安全的“三把锁”

检查维度 核心问题 一句话规则
你是谁 Token是否有效?是否过期? 后端必须校验Token
你只能看到自己的 用户A能不能看用户B的订单? 后端必须关联Session用户ID与业务ID
你只能做能做的事 小白用户能不能点管理员按钮? 后端必须做角色/权限检验

特别提醒:小程序安全很大程度依赖后端,如果后端接口没有做好权限校验,前端代码写得再漂亮也没用,建议使用自动化工具(如Burp Suite)批量扫描弱口令、未授权访问、SQL注入等常见漏洞。

抱歉,评论功能暂时关闭!