当奈飞的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，也很到位。

web2

但是从web2的角度看，他获取官方签名的环节，其攻破成本几乎为0。这点可以类比传统web2上营销发行优惠券，一直都是企业的大挑战。

笔者本身从业web2业务安全风控5年，出于职业习惯，也补充下web2好用的安全防护对抗方案。

其核心是依赖于账号安全体系健全，黑灰产黑名单数据库的全面性，实时对抗策略的体系。

一个要健全的web2上营销反作弊场景保护，其需要4大环节：

1：业务风险评估 = 产品逻辑+数据埋点+埋点处理+动态埋点对抗

2：离线策略建模 = 策略研发+验证+上线评估

3：现网持续对抗 = 策略灰度+策略监控+策略迭代+动态攻防+客诉反馈+黑产情报

4：决策处置对抗 = 行为及时阻断+人机验证+身份核验

其中高度依赖黑数据质量，这是成本对抗的基础，核心有设备指纹库，IP画像库，手机画像库，账号画像库等等

最后是持续性的算法加强策略检测，比如异常检测，团伙发现，行为检测等。

总之

web2的基础不丢才有跑鞋的辉煌，web3是营销利器但也不是独立生态，长期看会与web2诸多基建共存。

附录：https://eips.ethereum.org/EIPS/eip-1271

继续滑动看下一个