前言

中秋假期期间，有一件事冲上了热搜。让人一惊，阿里云盘忽然出了一个BUG，用户相册数据竟能越过鉴权和隔离策略直接展示在其他用户面前！这件事对所有阿里云盘用户来说，无异于说是灾难的，相当于多人的隐私直接展现在一个大屏幕上，谁都可以看。

特别感谢我的习惯，哦不，应该感谢我的倔强？在20年前的安卓手机打开网盘APP后默认就会访问访问我的 通讯录/相册/短信 等信息，直接默认我同意就自动上传上去了！因此我也被迫的学会了权限管理，在ios平台虽然没有默认同意，也要经常点击拒绝才可以。

但是具体的记录看了下，过程大概如下：

创建一个新的相册
筛选过滤数据仅展示相册，就出来了😂

BUG猜想

阿里的技术通常使用Java方案，在Java中很流行一种判空策略，下面简单的使用MP的一个例子做一个简单的猜想，仅猜想哈。并没有什么内部消息，是自己的意淫。

通常我们会在程序中严格的指定用户ID，但是很多人的代码是这样写的：

// 形参忽略，主要有 userId、albumId、status
public List<DriveAlbum> selectDriveAlbum(...) {
    LambdaQueryWrapper<DriveAlbum> queryWrapper = new LambdaQueryWrapper<>();

    //用户id精确eq，判断不为空再拼接
    queryWrapper.eq(StringUtils.isNotBlank(userId), "user_id", userId);
    //相册id精确eq，判断不为空再拼接
    queryWrapper.eq(StringUtils.isNotBlank(albumId), "album_id", albumId);
    queryWrapper.eq(status != null, "status", status);
    return driveAlbumMapper.selectList(queryWrapper);
}

看完上面的策略，假如实参传递来userId和albumId，则SQL可能会是如下的效果：

1 2	#查询10086用户权限下的10010相册 SELECT * FROM drive_album WHERE user_id ="10086" and album_id="10010" ORDER BY create_time DESC;

但是假如实参传的都为null或者不命中判断呢？

1 2	#查询所有用户的所有相册 SELECT * FROM drive_album ORDER BY create_time DESC;

这样就会直接越权访问别人的数据了，为什么为null就不清楚了

当然，我认为阿里绝对不可能没有预案，肯定有更复杂的检查和策略来杜绝这种跨账号之间的资产访问。

我上面仅仅是用来猜想的，仅仅是简单的举例子，仅用来参考。阿里的响应速度还是很快的，看到后很快就做了拦截和修复，最快的保证了用户的数字资产安全，点赞👍

应对策略

完善的自动化测试：不能仅做接口测试，还需要每次都进行模拟点击测试
1. 满足测试的覆盖率，核心功能的通过率
2. 在CI/CD流程上增加测试覆盖率check，通过后再进入部署流程
常态化的code review：code review的过程可以让队友帮我们发现问题，降低问题的发生概率

在编程方面严格限制，一旦检测到重要的数据被越权访问，直接拒绝本次请求。简单例子如下

public List<DriveAlbum> selectDriveAlbum(...) {
    // 判断 userId 或 albumId 是否为 null
    if (StringUtils.isBlank(userId) || albumId == null) {
        throw new BizException("网络有问题，请稍后再试哦");
    }
    // 构建 MyBatis Plus 的 LambdaQueryWrapper
    LambdaQueryWrapper<DriveAlbum> queryWrapper = new LambdaQueryWrapper<>();

    // 忽略
  }

完善报警机制，一旦抛出相关报警发送到相关群聊中@相关值班同学，做到最快发现问题、最快响应问题
统一登录系统 & 统一拦截系统在重要的操作中，如果相关隔离标识异常，尽量不做放行。宁可被投诉，也不可把数据越权输出
学习阿里云盘，如果实在因为不可抗力因素不能快速的修复，则直接把数据全部拦截，影响面做到最小