当奈飞的NFT忘记了web2的业务安全

Posted 2023-04-03 十四君-web3

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了当奈飞的NFT忘记了web2的业务安全相关的知识，希望对你有一定的参考价值。

奈飞 Netflix 是市值达800亿美金的视频类娱乐服务公司，在 190 多个国家/地区拥有 2.22 亿付费会员如此巨头又怎会放过web3的风口呢？

因此在近期X2earn的火热下，他也创意独裁出了个Watch to Eran

官方入口：https://lovedeathandart.com/

大概是会员在阅读影片的过程中，会随机出现一个二维码，结合用户的以太坊地址后，官方会签名信息，用户将可以得到一个signature 数值，而有了这个值，即可在netflix官方发布的NFT合约中，铸造一枚nft，如图美观度上十分不错结合上稳定的经济模型，或许又是一个跑鞋般的顶流项目！

所以一开始，大家还想冲一波会员，来慢慢watch 2 eran

然而，万万没想到，这个得到官方进行签名的过程，他竟然毫无防护！

活动开始，当web3科学家们满怀激动的心，颤抖的手来抓包想等到收到二维码的时候，赫然发现，原来扫码签名无需同web2账号进行鉴权，也无风控逻辑？？？

只需要构建以下的请求，将自己的以太坊地址和目标中的系列号写入

curl 'https://us-central1-ldr-prod.cloudfunctions.net/api/sign' \\
  -H 'authority: us-central1-ldr-prod.cloudfunctions.net' \\
  -H 'accept: application/json, text/plain, */*' \\
  -H 'accept-language: zh-CN,zh;q=0.9,en;q=0.8' \\
  -H 'cache-control: no-cache' \\
  -H 'content-type: application/json' \\
  -H 'dnt: 1' \\
  -H 'origin: https://lovedeathandart.com' \\
  -H 'pragma: no-cache' \\
  -H 'referer: https://lovedeathandart.com/' \\
  -H 'sec-fetch-dest: empty' \\
  -H 'sec-fetch-mode: cors' \\
  -H 'sec-fetch-site: cross-site' \\
  -H 'user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (Khtml, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1' \\
  --data-raw '"address":"以太坊地址","category":"系列号0-9"' \\
  --compressed

mac系统可以直接在命令行发出，window系统可以用postman等请求包构建工具，即可发出此请求。返回的信息里会有一个signature。

然后去官方合约地址

https://etherscan.io/address/0xfd43d1da000558473822302e1d44d81da2e4cc0d#writeContract

写入，随意编写个data值（合约中并未对其校验），以及对应的系列号，即可进行mint。

而且几小时后，就有同学制作一键式脚本，进一步降低操作难度。

由于此nft获取的代价太低，基本平均在当前20wei的gas成本下，截止5.20- 9点已经有5W 次交易，大多数是mint的操作。当然出了bug后，基本后续此nft的价格不会太高，大家也就相当于参与体验玩玩

但是对于 Netflix 而言，一个可能媲美stepn的创意就在最基础的web2业务流程中被爆破了。

虽然某种意义上，这个bug的传播效果似乎完全超出了活动本身的策划。。

从安全的角度解读

web3

我们来分析下合约可以看出，其实他web3部分的合约安保措施是相对到位的。

function mint(
        uint256 _category,
        bytes memory _data,
        bytes memory _signature
) external nonReentrant whenNotPaused 
        require(isSignatureValid(_category, _signature), "LDRT: Invalid signature");
        require(_category >= 1, "LDRT: Invalid category. It is less than 1.");
        require(_category <= 9, "LDRT: Invalid category. It is greater than 9.");

        bytes32 hashAdrrCategory = keccak256(abi.encodePacked(msg.sender, _category));
        bool hasMinted = categoriesMinted[hashAdrrCategory];
        require(
            !hasMinted,
            "LDRT: Address already has token for that category."
        );
        categoriesMinted[hashAdrrCategory] = true;

        // 1 is because it will mint 1 token for that category
        _mint(msg.sender, _category, 1, _data);

1：属于标准设计模式，结合eip1271 的验签方式来确定白名单资格，1271是为合约进行签名所设计的，其指定的isValidSignature可以设定任意验签逻辑，如支持单签、多签、门限签名等。

如果不做这样的签名验证，则在此活动中，如何管控mint白名单就是个高成本的问题了。

因为活动本身在于激励用户持续观看，

如果积累一段时间的白名单merkle树根到链上，则用户受到激励反馈会比较长

而如果每得到一个用户，就上白名单一次，就会造成活动方的高成本

2：其次合约还会再将此钱包地址+系列号，纳入hasMinted中，防止重放，并且实现的方式是先修改权限再操作mint，也很到位。