区块链 | 由外部实体导致的 NFT 安全问题

2024-04-30 17:12

本文主要是介绍区块链 | 由外部实体导致的 NFT 安全问题,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

🦊原文: Understanding Security Issues in the NFT Ecosystem

🦊警告: 本文只记录了原文的第 6 节。



1 问题描述

NFT 所指向的数字资产(图片、视频等)必须是可以访问的,这样 NFT 才具有意义。NFT 可以通过以下两种方式链接数字资产:

( i ) (\mathsf{i}) (i) 如果 NFT 合约是 ERC-721 兼容的并且实现了元数据扩展,那么由该合约创建的代币在链上包含一个 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url,它指向一个元数据(JSON)。反过来,这个元数据又包含一个 i m a g e _ u r l \mathsf{image\_url} image_url 字段,该字段指向实际的数字资产。

JSON 是指元数据采用的是 JSON 格式。

( i i ) (\mathsf{ii}) (ii) 然而,许多较老的代币不符合标准,并且不包含任何链上的 i m a g e _ u r l \mathsf{image\_url} image_url。相反,它们使用一些临时的、链下方案来链接一个资产。对于这样的 NFT,NFT 市场(NFTM)实施自定义支持,以便它们能够生成有效的图片 URL 。

NFTM 的全称是 NFT Marketplace

由于元数据和数字资产都存储在链下,它们并不享受与 NFT 本身相同的不可篡改性保证。当任何 URL 变得无法访问时,就会打破 NFT 与相应数字资产之间的链接。实际上,这些 URL 通常指向分布式存储服务(例如 IPFS),或者是中心化存储(例如一个网页域名或 Amazon S3 存储桶)。

不知道这段说的是第二种方式,还是都有在说?

对于 IPFS URL,如果 NFT 所有者有所意识,TA 可以通过固定资源(即持续存储它)来保持 NFT “活跃”。即使这样做,也可能会有问题,因为 NFT 并不存储实际资源的哈希值,而是存储指向 IPFS 网关 Web 服务的 URL 。如果网关变得不可用,NFT “断裂”。总的来说,包含指向 NFT 所有者控制之外域名的 URL 的 NFT,在相应的域名消失时有失效的风险。



2 定量分析

我们进行了一次分析,以量化由于上述原因而 “丢失” 的 OpenSea NFT 的数量。

截至 2021 年 6 月 15 日,我们从 OpenSea 获得的 12 , 215 , 650 \mathsf{12,215,650} 12,215,650 个资产中,只有 3 , 175 , 644 \mathsf{3,175,644} 3,175,644 个资产具有有效的 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url 字段。通过查询 OpenSea 的 API,我们获得了 8 , 363 , 550 \mathsf{8,363,550} 8,363,550 个具有非空 i m a g e _ u r l \mathsf{image\_url} image_url 字段的资产。

具有有效 m e t a d a t a _ u r l \mathsf{metadata\_url} metadata_url 的才 3 , 175 , 644 \mathsf{3,175,644} 3,175,644 个,怎么 i m a g e _ u r l \mathsf{image\_url} image_url 非空的都有 8 , 363 , 550 \mathsf{8,363,550} 8,363,550 个?

剩下的 3 , 860 , 607 \mathsf{3,860,607} 3,860,607 个资产没有 i m a g e _ u r l \mathsf{image\_url} image_url 字段,这意味着它们是直接托管在 OpenSea 上的(内容创作者可以选择留空 i m a g e _ u r l \mathsf{image\_url} image_url 字段,在这种情况下 OpenSea 处理托管)。

OpenSea 处理托管应该是指,将数字资产存储在 OpenSea 的集中式数据库中。

我们首先检查图像和元数据 URL 是否指向托管在 IPFS 上的资源。接着,我们检查 URL 是否仍然可以访问。为此,我们执行一个 HTTP HEAD 查询。如果查询返回的响应代码不是 200(OK),我们接下来执行一个 HTTP GET 查询。如果那个查询也返回一个非 200 的响应代码,我们将那个 URL 标记为不可访问。我们采取两步方法是为了优化性能,避免因为一些不支持 HEAD 查询的 Web 服务器而产生假阴性(false negatives)。

HTTP HEAD 用于检查网页是否更新,并不获取资源的实际内容。

此外,托管资产的服务器在测试时可能掉线,但后来又恢复在线。为了考虑这种可能性,我们在 15 天的时间内重复了上述 URL 检查三次。每次都只测试前一次尝试中被标记为不可访问的资产。只有当三次尝试都一致认为资产不可访问时,该资产才会最终被标记为不可访问。

在这里插入图片描述

上图报告了我们的发现。两个重要的观察结果是:

( i ) (\mathsf{i}) (i) 在我们数据集中的 6 月至 12 月期间,只有 3.91 \mathsf{3.91} 3.91% 托管在 IPFS 上的资产(图像)和 9.04 \mathsf{9.04} 9.04% 托管在 IPFS 上的元数据记录消失了;如预期的那样,托管在 IPFS 上的 NFT 比那些托管在非 IPFS 域名上的 NFT 更不可能消失。

( i i ) (\mathsf{ii}) (ii) 尽管 IPFS 应该更能抵抗资产消失,但大多数资产 URL( 88.71 \mathsf{88.71} 88.71%)以及元数据 URL( 80.69 \mathsf{80.69} 80.69%)都是托管在非 IPFS 域名上。查看所有丢失的 NFT,它们通过 118 , 294 \mathsf{118,294} 118,294 笔交易产生了惊人的收入,总额达到 1.60761805 \mathsf{1.60761805} 1.60761805 亿美元。不仅如此,由于我们在第 5 节中讨论的缓存问题,它们中的一部分可能仍然在流通中。正如这项分析所示,持久性是 NFT 领域的一个紧迫问题。



3 补充:缓存问题

无效缓存: 在展示正在销售的 NFT 时,OpenSea 和 Rarible 使用本地缓存层来避免重复请求获取关联的图片。如果图片被更新,或者消失了,缓存就会不同步。这可能会误导买家购买一个资产不存在,或者与 NFT 显示的资产不同的 NFT,因为他们使用了过时的缓存。

定量分析: 为了了解这个缓存问题可能的潜在影响,我们测量了在我们 OpenSea 数据集中有多少个 i m a g e _ u r l \mathsf{image\_url} image_url 无法被访问,但 OpenSea 仍然提供相应的缓存版本。

在总计 12 , 215 , 650 \mathsf{12,215,650} 12,215,650 个 NFT 中,有 3 , 945 , 231 \mathsf{3,945,231} 3,945,231 个( 32.30 \mathsf{32.30} 32.30%)代币的 i m a g e _ u r l \mathsf{image\_url} image_url 无法访问。然而,OpenSea 仍然缓存了其中 2 , 691 , 030 \mathsf{2,691,030} 2,691,030 个( 68.21 \mathsf{68.21} 68.21%)无法访问的图片,从而创造了资产仍然存在的错觉。这样一个损坏的系列是Gods Unchained,这是一个经过验证的系列,其总体交易量为 19.8 \mathsf{19.8} 19.8K 以太币。

这篇关于区块链 | 由外部实体导致的 NFT 安全问题的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/949442

相关文章

解决pandas无法读取csv文件数据的问题

《解决pandas无法读取csv文件数据的问题》本文讲述作者用Pandas读取CSV文件时因参数设置不当导致数据错位,通过调整delimiter和on_bad_lines参数最终解决问题,并强调正确参... 目录一、前言二、问题复现1. 问题2. 通过 on_bad_lines=‘warn’ 跳过异常数据3

解决RocketMQ的幂等性问题

《解决RocketMQ的幂等性问题》重复消费因调用链路长、消息发送超时或消费者故障导致,通过生产者消息查询、Redis缓存及消费者唯一主键可以确保幂等性,避免重复处理,本文主要介绍了解决RocketM... 目录造成重复消费的原因解决方法生产者端消费者端代码实现造成重复消费的原因当系统的调用链路比较长的时

深度解析Nginx日志分析与499状态码问题解决

《深度解析Nginx日志分析与499状态码问题解决》在Web服务器运维和性能优化过程中,Nginx日志是排查问题的重要依据,本文将围绕Nginx日志分析、499状态码的成因、排查方法及解决方案展开讨论... 目录前言1. Nginx日志基础1.1 Nginx日志存放位置1.2 Nginx日志格式2. 499

kkFileView启动报错:报错2003端口占用的问题及解决

《kkFileView启动报错:报错2003端口占用的问题及解决》kkFileView启动报错因office组件2003端口未关闭,解决:查杀占用端口的进程,终止Java进程,使用shutdown.s... 目录原因解决总结kkFileViewjavascript启动报错启动office组件失败,请检查of

MyBatis-Plus 自动赋值实体字段最佳实践指南

《MyBatis-Plus自动赋值实体字段最佳实践指南》MyBatis-Plus通过@TableField注解与填充策略,实现时间戳、用户信息、逻辑删除等字段的自动填充,减少手动赋值,提升开发效率与... 目录1. MyBATis-Plus 自动赋值概述1.1 适用场景1.2 自动填充的原理1.3 填充策略

SpringBoot 异常处理/自定义格式校验的问题实例详解

《SpringBoot异常处理/自定义格式校验的问题实例详解》文章探讨SpringBoot中自定义注解校验问题,区分参数级与类级约束触发的异常类型,建议通过@RestControllerAdvice... 目录1. 问题简要描述2. 异常触发1) 参数级别约束2) 类级别约束3. 异常处理1) 字段级别约束

Python错误AttributeError: 'NoneType' object has no attribute问题的彻底解决方法

《Python错误AttributeError:NoneTypeobjecthasnoattribute问题的彻底解决方法》在Python项目开发和调试过程中,经常会碰到这样一个异常信息... 目录问题背景与概述错误解读:AttributeError: 'NoneType' object has no at

Spring的RedisTemplate的json反序列泛型丢失问题解决

《Spring的RedisTemplate的json反序列泛型丢失问题解决》本文主要介绍了SpringRedisTemplate中使用JSON序列化时泛型信息丢失的问题及其提出三种解决方案,可以根据性... 目录背景解决方案方案一方案二方案三总结背景在使用RedisTemplate操作redis时我们针对

Kotlin Map映射转换问题小结

《KotlinMap映射转换问题小结》文章介绍了Kotlin集合转换的多种方法,包括map(一对一转换)、mapIndexed(带索引)、mapNotNull(过滤null)、mapKeys/map... 目录Kotlin 集合转换:map、mapIndexed、mapNotNull、mapKeys、map

Nginx安全防护的多种方法

《Nginx安全防护的多种方法》在生产环境中,需要隐藏Nginx的版本号,以避免泄漏Nginx的版本,使攻击者不能针对特定版本进行攻击,下面就来介绍一下Nginx安全防护的方法,感兴趣的可以了解一下... 目录核心安全配置1.编译安装 Nginx2.隐藏版本号3.限制危险请求方法4.请求限制(CC攻击防御)