安全指引

开发原则与注意事项

本文档整理了部分小程序开发中常见的安全风险和漏洞，用于帮助开发者在开发环节中发现和修复相关漏洞，避免在上线后对业务和数据造成损失。开发者在开发环节中必须基于以下原则：

  1. 互不信任原则，不要信任用户提交的数据，包括第三方系统提供的数据，必要的数据校验必须放在后台校验。
  2. 最小权限原则，代码、模块等只拥有可以完成任务的最小权限，不赋予不必要的权限。
  3. 禁止明文保存用户敏感数据。
  4. 小程序代码（不包括云函数代码）跟传统 Web 应用的前端代码类似，可被外部获取及进行反混淆，重要业务逻辑应放在后台代码或云函数中进行。
  5. 后台接口调用以及云函数调用，必须进行有效的身份鉴权。

通用

接口鉴权

接口鉴权是指后台接口（包括自建后台接口与云函数）在被调用时需要对本次接口调用进行权限校验，否则容易发生越权行为。如商品删除接口，后台在收到请求时应当校验调用者的身份信息（如 openid、 ip 地址、开发者自定义的登录态信息等），只有指定用户才可以通过校验进行删除。

越权通常分为平行越权和垂直越权：

  • 平行越权

    平行越权是指相同角色之间的越权。 A1、 A2 都是普通用户， A1 通过请求后台接口 userinfo.php?id=A1 来获取用户 A1 自己的信息，如果 userinfo.php 没有进行权限校验，用户 A1 把请求改为 userinfo.php?id=A2 便可以获取到 A2 用户的信息，造成 A2 用户信息的泄露。

  • 垂直越权

    垂直越权是指不同角色之间的越权。 B1 是管理员， B2 是普通用户，管理员 B1 通过请求后台接口 getalluserinfo.php 可以获取所有注册用户的信息，如果 getalluserinfo.php 没有进行权限校验， B2 用户也可以请求 getalluserinfo.php 来获取所有注册用户的信息，出现越权行为。

开发建议：

  1. 敏感数据、能力相关接口需要在后台进行鉴权。通常可校验 openid、 IP 地址、自定义登陆态等信息。

  2. 鉴权逻辑应放在后台进行，不应在小程序前端以隐藏页面、隐藏按钮等方式来代替。参照原则4。

  3. 鉴权代码示例（仅供参考）

    • 自建后台鉴权

      1. function actionDelete(){
      2.     $item_id = $_POST["item_id"]; 
      3.     $openid = $_POST["openid"];
      4.     $ip = $_SERVER['REMOTE_ADDR'];
      5.     $user_role = $_SESSION["user_role"];
      6.     if ($openid === "xxx" &&
      7.         $ip === "192.168.0.101" &&
      8.         $user_role === "admin") {
      9.             // 进行删除操作
      10.             // ...
      11.             return 0;
      12.         } else {
      13.             // 记录非法请求
      14.             // ...
      15.             return -1;
      16.         }
      17. }

    • 云函数接口鉴权

      1. exports.main = async (event, context) => {
      2.     const { OPENID, APPID, UNIONID } = cloud.getWXContext();
      3.     if (OPENID === "xxx") {
      4.         // 进行删除操作
      5.         // ...
      6.     } else {
      7.         // 记录非法请求
      8.         // ...
      9.     }
      10. }

代码管理与泄漏

  1. 当使用 git、 svn 等版本管理工具时，会产生 .git 等目录。某些编辑器或软件也会在运行过程中生成临时文件。若这些目录或文件被带到生产环境，则可能发生源码泄漏。

  2. 使用小程序代码管理平台或 github 等第三方平台时需要注意项目权限，不要公开敏感、内部项目。

开发建议：

  1. 备份文件和版本管理工具产生的文件不要同步到 Web 目录下。
  2. 禁止外部访问 .git 等目录与文件。
  3. 在小程序代码管理平台等管理平台内配置适当的访问权限。

小程序

信息泄露

敏感信息是指一旦泄露可能会对开发者的业务、合作伙伴和用户带来利益损害的数据，包括但不限于帐号 Appsecret、特权帐号信息、后台加密密钥、登录账户密码、用户身份证号、手机号、银行卡号等。

开发建议：

  1. 敏感信息不应以明文、注释、可逆的编码方式（如 base64）、不安全散列函数（如 MD5、 SHA1）等形式出现在小程序文件内。

  2. 部分敏感信息如用户的银行卡号、手机号等需要用于展示的，需要进行脱敏处理。常用脱敏规范如下：

    敏感信息类型展示样例
    姓名名字只有两个字，对第一个字打码，如：三。 多于两个字，只保留第一个和最后一个，其余都打码，如：王四、欧五
    身份证只显示第一位和最后一位，如：3**1
    手机号除去手机国际码后，手机号位数不少于10位时，只显示前三位和最后两位，如：156**77。手机号位数少于10位时，只显示前两位和后两位，如：12*89。国家码可以完全显示。
    银行卡只显示最后4位，如：**1234

  3. 如果小程序存在敏感信息泄露的问题，微信开放平台将有可能下架该小程序，并暂停该小程序的相关服务。

后台（包括云函数与自建后台）

注入漏洞

注入漏洞（SQL、 命令等）通常指用户绕过后台代码限制，直接在数据库、 shell 内执行自定义代码。

常见的注入漏洞有：

SQL 注入

SQL 注入是指 Web 程序代码中对于用户提交的参数未做有效过滤就直接拼接到 SQL 语句中执行，导致参数中的特殊字符打破了 SQL 语句原有逻辑，黑客可以利用该漏洞执行任意 SQL 语句。

开发建议：

  1. 使用数据库提供的参数化查询来进行数据库操作，不允许直接通过拼接字符串的方式来合成 SQL 语句。
  2. 如果存在部分情况需要通过拼接的方式来合成 SQL ，拼接的变量必须要经过处理：
    • 对于整数，需要判断变量是否为整数类型。
    • 对于字符串，需要对单引号、双引号等做转义处理。
  3. 避免 Web 应用显示 SQL 的报错信息。
  4. 保证 Web 应用里每一数据层的编码统一。

命令注入

命令注入漏洞是指 Web 应用未对用户可控参数进行有效过滤，攻击者可以构造恶意参数拼接到命令上来执行任意命令。

开发建议：

  • 对用户输入的数据（如 ;、|、&等）进行过滤或转义。

弱口令

弱口令指管理后台的用户名密码设置得较为简单或者使用默认帐号。攻击者可以通过登录这些帐号修改后台数据或进行下一步的入侵操作。

开发建议：

  1. 后台服务禁用默认帐号，修改后台弱口令。
  2. 敏感服务增加二次验证机制，如短信验证码、邮箱验证码等。

文件上传漏洞

文件上传漏洞是指 Web 应用允许用户上传指定文件，但未对文件类型、格式等做合法性校验，导致可以上传非预期格式的文件。

开发建议：

  • 正确解析上传文件的文件类型，通过白名单的方式限制可上传的文件类型。

文件下载

文件下载漏洞是指 Web 应用允许用户通过指定路径和文件名的方式来下载对应的文件，但未正确限制可下载文件所在的目录范围，导致预期范围外的文件被下载泄露。

开发建议：

  1. 正确限制可下载文件所在的目录范围
  2. 通过指定文件 id 的方式来查找下载对应的文件

目录遍历

目录遍历是指由后台服务对用户输入验证不足或配置不严谨导致的服务器目录内容泄漏。外部可能通过目录遍历获取系统文件、后台代码等敏感文件。

开发建议：

  1. web 服务配置

    • 服务端禁止展示目录
    • 设置目录访问权限
    • 在每个目录下放置一个空的 index.html 页面

  2. web 应用代码

    • 严格检查文件路径参数，限定文件的范围

条件竞争

条件竞争比较常见的例子是攻击者通过并发 https 请求而达到多次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。

  • 漏洞代码示例

    1. // 从DB里查询该用户剩余获奖次数，初始值为1
    2. int remain_times = SelectRemainTimes();
    4. if(remain_times > 0){
    5.     EarnRewards();          // 用户获得奖励
    6.     ClearRemainTimes();     // 在DB里把该用户的剩余获奖次数清零
    7. }

    开发者的设计本意是只允许用户获得一次奖励，但当出现并发请求时，有可能出现请求 A 和请求 B 都刚好执行完第2行代码的情况，此时两个请求的 remain_times 都为1，也就是可以通过第4行代码的判断，获得两次奖励。

开发建议：

  • 对关键（完整）逻辑加锁操作或把关键逻辑以队列任务的形式去进行处理。