- 综合排序
- 最热优先
- 最新优先
- 来自专栏nft市场
智能合约安全——selfdestruct攻击
selfdestruct函数（自毁函数）由以太坊智能合约提供，用于销毁区块链上的合约系统。当合约执行自毁操作时，合约账户上剩余的以太币会发送给指定的目标，然后其存储和代码从状态中被移除。 selfdestruct函数虽然能在紧急情况下帮助开发人员删除智能合约并将合约内的余额转移到指定的地址，但这一特性也被不法分子利用，使它成为了攻击手段。 玩家每次玩游戏时都会调用 EtherGame.deposit 函数向合约中先打入一个ETH，随后函数会检查合约中的余额(balance)是否小于等于 7 ，只有合约中的余额小于等于 7 时才能继续否则将回滚 攻击合约 图片 攻击者调用攻击函数attack（）销毁合约并将合约中的余额强制转账到“幸运7”的游戏合约地址，制造出游戏合约查询余额address(this).balance大于7的情况，导致函数回退， 修复的代码： 图片 如果想了解更多的智能合约和区块链知识，欢迎到区块链交流社区CHAINPIP社区，一起交流学习~ 社区地址：https://www.chainpip.com/
80620编辑于 2022-07-27 - 来自专栏nft市场
智能合约安全——重入漏洞
众所周知，以太坊的转账不仅可以在钱包地址之间进行，合约与钱包地址之间、合约与合约之间也可以，而合约在接收到转账的时候会触发 fallback 函数执行相应的逻辑，这是一种隐藏的外部调用。 攻击者就会利用这一点，在合约的fallback 函数中写入恶意逻辑重新进入到被攻击的合约内部，让被攻击的合约执行非预期的外部调用，从而到达获取不正当利益的目的。 函数一直提币从而将合约账户清空。 攻击合约下面我们看看攻击者编写的攻击合约中的攻击手法是否与我们的漏洞分析相同：图片我们看到 EtherStore 合约是一个充提合约，我们可以在其中充值和提现。 记住所有涉及到外部合约调用的代码位置都是不安全的。那么智能合约中的重入攻击就讲解完了，如果想了解更多的区块链知识，或是有什么疑问，可以到区块链交流社区CHAINPIP来，一起学习和交流。
93320编辑于 2022-07-29 - 来自专栏nft市场
智能合约安全——delegatecall (1)
举个例子： 合约A 图片 合约B 图片 当合约B调用testDelegatecall()函数时，合约B的地址c的值会变为合约A的地址，而地址a则是不变。 因为合约A的函数test()改变的是插槽slot1的值，同样的在合约B中运行时，改变的也是插槽slot1的值，即地址c的值。 目标合约 图片 漏洞分析 我们可以看到有两个合约，Lib 合约中只有一个 pwn 函数用来修改合约的 owner，在 HackMe 合约中存在 fallback 函数，fallback 函数的内容是使用 Lib 合约中恰好有名为 pwn 的函数，于是便在HackMe 合约中运行了pwn函数； 4.pwn函数修改了插槽slot0位置（即HackMe 合约的拥有者）的值为msg.sender（即攻击者），最终导致了 在使用 delegatecall 时应注意被调用合约的地址不能是可控的； 2. 在较为复杂的合约环境下需要注意变量的声明顺序以及存储位置。
46130编辑于 2022-08-02 - 来自专栏nft市场
智能合约安全性
以太坊智能合约是极为灵活的。它能够存储超过非常大量的虚拟货币（超过十亿美元），并且根据先前部署的智能合约运行不可修改的代码。 智能合约代码通常无法修改来修复安全漏洞，因此从智能合约中被盗窃的资产是无法收回的，且被盗资产极难追踪。 由于智能合约问题而被盗取或丢失的价值总额很容易超过 10 亿美元。 仅仅在项目结束时对您的智能合约进行审计已经不足以成为项目的唯一安全考虑。 安全性来源于适当的设计和开发过程，所以在您编写第一行智能合约代码之前，安全性就应该被考虑。 重入攻击重入攻击时在编写智能合约代码时应该考虑的最大且最重要的安全问题。 虽然以太坊虚拟机不能同时运行多个合约，一个合约可以调用另一个合约来暂停一个合约的执行和内存状态，直到被重新调用。 它检测为以太坊、Hedera、Quorum、Vechain、Roostock、Tron 和其他与 EVM 兼容的区块链构建的智能合约中的安全漏洞。
1.1K10编辑于 2022-08-12 - 来自专栏nft市场
智能合约安全——溢出漏洞
图片如果一个合约有溢出漏洞的话会导致计算的实际结果和预期的结果产生非常大的差异，这样轻则会影响合约的正常逻辑，重则会导致合约中的资金丢失。 所以当我们看到 0.8 版本以下的合约时，就要注意这个合约可能出现溢出问题。 攻击合约下面我们来看看攻击合约：图片这里我们将使用 Attack 攻击合约先存入以太后利用合约的溢出漏洞在存储未到期的情况下提取我们在刚刚 TimeLock 合约中存入并锁定的以太：1. 首先部署 TimeLock 合约；2. 再部署 Attack 合约并在构造函数中传入 TimeLock 合约的地址；3. 如果想了解更多的智能合约和区块链知识，欢迎到区块链交流社区CHAINPIP社区，一起交流学习~社区地址：https://www.chainpip.com/
85330编辑于 2022-07-28 - 来自专栏nft市场
智能合约安全——delegatecall (2)
目标合约漏洞分析这次的攻击目标依然是获得 HackMe 合约中的 owner 权限，我们可以看到两个合约中除了 HackMe 合约中的构造函数可以修改合约的 owner 其他地方并没有修改 owner 的函数，但是却可以修改位置slot0的值，而HackMe 合约中插槽slot0表示的便是Lib的地址，那么我们就先修改Lib的地址为我们的地址，再次调用HackMe 合约时就会运行我们合约中的逻辑，那么想改哪个位置插槽的值不就都由我们控制了吗 攻击合约下面是我们本次的攻击合约：接下来我们来看看攻击的整个逻辑：1. 修复建议我们在合约的开发中使用delegatecall要时刻注意其被调用的合约地址要始终在我们设计的逻辑内运行，不能让其有可能超出我们设计时的适用范围，一旦出现了超出我们预期设计的情况，那么合约就有可能被不法之徒利用 如果想了解更多的智能合约和区块链知识，欢迎到区块链交流社区CHAINPIP社区，一起交流学习~社区地址：https://www.chainpip.com/
37920编辑于 2022-08-03 - 来自专栏nft市场
智能合约安全——随机数
本次我们将带大家了解智能合约中一个经常被用到的东西——随机数。智能合约的开发中常常会用到随机数，例如 Lottery 和现在流行的 NFT 数字藏品的属性等都需要用到随机数。 当然这种方法也会有一些安全风险，例如依赖第三方给出的随机数种子的话同样会存在第三方作弊或者受贿的情形，即使是自己搭建的随机数服务也可能因为故障等原因无法使用，项目方也有可能操控随机数对 DApp 的运行和用户造成重大的损失 接下来我们还是用合约代码来给大家演示弱随机数可能带来的危害。 下面我们来看攻击合约：攻击合约图片下面我们先来分析攻击流程：攻击者调用Attack.attack()函数，它模拟了 GuessTheRandomNumber 合约中随机数的生成方式生成随机数后调用 guessTheRandomNumber.guess 如果想了解更多的智能合约和区块链知识，欢迎到区块链交流社区CHAINPIP社区，一起交流学习~社区地址：https://www.chainpip.com/
89830编辑于 2022-08-05 - 来自专栏网络安全攻防
智能合约安全审计技术概览
文章前言 智能合约是区块链技术的重要组成部分，它能够自动执行代码并将结果写入区块链以实现各种业务场景，然而由于智能合约本质上是代码，因此也存在着相应的安全风险，如果智能合约存在漏洞，黑客就有可能利用这些漏洞进行攻击 ，导致资产损失甚至系统崩溃，因此对智能合约进行安全审计是至关重要的，本文将概述智能合约安全审计技术的相关知识为读者带来更深入的了解 智能合约 智能合约是一种基于区块链技术的自动化合约，它可以在没有第三方干预的情况下自动执行合约条款并将结果记录在区块链上 编码设计 DASP Top 10归纳了智能合约常见的安全漏洞，智能合约开发人员在开发合约之前可以先研习智能合约安全漏洞以规避在开发合约时出现安全漏洞，合约审计人员可根据DASP Top 10对智能合约已有安全漏洞进行快速审计检查 场景覆盖面充分以及合约代码的覆盖率 安全审计 智能合约在正式上线之前建议先寻找可靠的、可信任的第三方区块链智能合约安全审计公司对合约的安全性进行安全审计评估，在初次审计完成后需要对合约中存在的安全漏洞进行修复调整 目前智能合约安全审计技术已经取得了一定的进展，但仍需要不断地进行研究和探索以应对日益复杂的区块链安全威胁，相信在未来，随着技术的不断进步和完善，智能合约安全审计将成为区块链应用开发的必要步骤，为区块链技术的发展提供重要的保障
1.5K40编辑于 2023-08-10 - 来自专栏网络安全攻防
智能合约安全之笔误安全问题
漏洞示例 示例合约如下所示： pragma solidity ^0.4.25; contract TypoOneCommand { uint numberOne = 2; function alwaysOne() public returns(uint a){ return numberOne =+ 1; } } 编译并部署合约之后调用alwaysOne来进行简易测试 防御措施 1、所有的数值运算操作全部采用SafeMath来实现 2、使用最新的编译器，最新版本编译器会自动检测是否存在类似的安全问题 ?
31420发布于 2021-07-21 - 来自专栏深入浅出区块链技术
关于编写安全的智能合约
译文出自：登链翻译计划[1] 译者：翻译小组[2] 校对：Tiny 熊[3] 译者注：本文作者是Matthew Di Ferrante[4]， 是 ZK Labs 的创始人，也是一个知名智能合约开发者及审计人员 然而，安全不是一个检查清单，安全是一个过程，不仅在编写代码时，而且在项目和架构的设计时就得首先考虑，安全应该成为你心态的一部分。 举个例子：现在有多少人在写智能合约时知道 ETH 可以在不调用回退函数的情况下被发送到合约中，即使该函数是不可支付的（non-payable?）？ 有多少智能合约在持有 USDC 时，在其内部逻辑中正确处理了这种情况：USDC 管理员将他们的地址列入黑名单，并使所有的转账调用失败或抹去其余额？ 最后，没有比阅读其他人的智能合约更好的投资回报率了--阅读比你差的人的代码，这样你可以从他们的错误中学习，来自比你好的人的代码，这样你可以看到你可能做错了什么，阅读尽可能多不同来源和领域的代码。
58920编辑于 2022-11-07 - 来自专栏Seebug漏洞平台
联盟链智能合约安全浅析
其中，Fabric联盟链平台智能合约具有很好的代表性，本文主要分析其智能合约安全性，其他联盟链平台合约亦如此，除了代码语言本身的问题，也存在系统机制安全，运行时安全，业务逻辑安全等问题。 语言特性问题 不管使用什么语言对智能合约进行编程，都存在其对应的语言以及相关合约标准的安全性问题。Fabric 智能合约是以通用编程语言为基础，指定对应的智能合约模块。 业务逻辑安全 •输入参数检查不到位 在编写智能合约时，开发者需要对每个函数参数进行合法性，预期性检查，即需要保证每个参数符合合约的实际应用场景，对输入参数检查不到位往往会导致非预期的结果。 •外部合约调用引入安全隐患 在某些业务场景中，智能合约代码可能引入其他智能合约，这些未经安全检查的合约代码可能存在一些未预期的安全隐患，进而影响链码业务本身的逻辑。 总结 联盟链的发展目前还处于项目落地初期阶段，对于联盟链平台上的智能合约开发，项目方应该强化对智能合约开发者的安全培训，简化智能合约的设计，做到功能与安全的平衡，严格执行智能合约代码安全审计(自评/项目组
2.7K10发布于 2020-08-31 - 来自专栏字节脉搏实验室
智能合约安全审计之路-条件竞争
一些概念 满足“条件竞争”的发生条件 并发访问：对同一个合约发起的调用的交易可以被“并发”的发生，虽然这些交易会被放进交易池线性执行，但是这些交易的执行顺序并不能得到保证。 共享对象：对于一个合约来说，合约的Storage变量就是所有合约函数调用中都能访问的共享对象 写操作：对Storage变量的更新，就是对共享对象的写操作 智能合约的特点 矿工在交易打包前(智能合约真正执行前 ，矿工可能选择对自己有利的打包顺序，而不会带来任何的后果 如果某个重要而秘密的值通过合约的参数传递，矿工可能发起中间人攻击 普通用户可以通过提高gas price的方式，尽可能尝试改变交易顺序，发起竞争条件 漏洞合约分析 ? tokens) 函数在用于授权用户转账额度，在owner修改用户的转账额度的时候，当该操作被用户监听到的时候，可以增大gas price提前转走这比额度 漏洞预防 对于提高gas price的行为：在合约中设置最高的
85010发布于 2020-05-12 - 来自专栏华仔的技术笔记
Solidity开发的智能合约安全建议
因此，每一个外部调用都会有潜在的安全威胁，尽可能的从你的智能合约内移除外部调用。当无法完全去除外部调用时，可以使用这一章节其他部分提供的建议来尽量减少风险。 尽管这些外部智能合约的函数可以被触发执行，但补贴给外部智能合约的2,300 gas，意味着仅仅只够记录一个event到日志中。 被调用的外部智能合约代码将享有所有剩余的gas，通过这种方式转账是很容易有可重入漏洞的，非常 不安全。 Ether时使用send() 或transfer()，已知明确内部无恶意代码的地址转账Ether使用call.value()()） 需要注意的是使用send() 或transfer() 进行转账并不能保证该智能合约本身重入安全 尽管如此，Interfaces在实现智能合约之前的设计智能合约阶段仍然有很大用处。
1.6K50发布于 2021-11-24 - 来自专栏nft市场
智能合约安全——私有数据访问
这次我们将了解如何访问合约中的私有数据（private 数据）。 目标合约 话不多说，直接上代码 图片 这次我们的目标合约是部署在 Ropsten 上的一个合约。 #code 漏洞分析 由上面的合约代码我们可以看到，Vault 合约将用户的用户名和密码这样的敏感数据记录在了合约中，我们知道合约中修饰变量的关键字仅限制其调用范围，这也就间接证明了合约中的数据均是公开的 ，可任意读取的，将敏感数据记录在合约中是不安全的。 ： 图片 这样我们就成功的将合约中的所有数据读取完成。 由此可见，合约中的私有数据也是可以读取的。 总结 大家可以看到，合约中的私有数据也是可以读取的，所以一定不要将任何敏感数据存放在合约中哦。
95220编辑于 2022-07-30 - 来自专栏字节脉搏实验室
智能合约安全审计之路-重入攻击
文章源自【字节脉搏社区】-字节脉搏实验室 作者-毕竟话少 描述：漏洞合约中某个函数中，使用call()方法发送eth,若eth的接收者为一个合约地址，则会触发该合约的fallback()函数。 若该合约是攻击者的恶意合约，攻击者可以在fallback()函数中重新调用漏洞合约的上述函数，导致重入攻击 核心问题：重要的合约变量在“重入”的过程中没有被修改，从而绕过了限制 ? wei ETH，这里受害者合约ReentrancyGame就部署完成了） 攻击者合约部署ReentrancyAttack(攻击者合约)，由于漏洞合约地址在提现的时候需要一定的ETH，所以这里在设置ReentrancyAttack 即可部署攻击者合约，部署完成后点击checkBalance查看当前账户余额为5 wei ETH,说明攻击者合约部署完成了 漏洞攻击-点击ReentrancyAttack(攻击者合约)attack即可攻击 漏洞预防 在将 Ether 发送给外部合约时使用内置的 transfer() 函数 。transfer转账功能只发送 2300 gas 不足以使目的地址/合约调用另一份合约（即重入发送合约）。
1.3K30发布于 2020-03-08 - 来自专栏网络安全攻防
智能合约安全之算术精度问题
在使用Solidity开发智能合约时，你会发现Solidity和普通编程语言有一个较大的区别——Solidity没有浮点型，且Solidity所有的数值运算结果都只会是整数，不会出现小数的情况，同时也不允许定义小数类型数据 算术精度安全问题 了解完上面Solidity的特性以及算术的运算优先级问题之后，我们下面来讨论一下本期正题——算术的精度安全问题。 确实，之前是定义了，但是这里就是在问，到底再编写智能合约时是先把同级运算中的乘法放到前面还是先把除法运算放到前面呢？也许，有读者已经发现问题了！ 而且当数量级达到一定程度时引起的误差将会更加大~ 安全思考 1、到底是该先乘法运算还是先除法运算呢？ 游戏合约中的游戏币的兑换功能、货币的买卖 文末小结 智能合约在发布之前应该在本地针对合约中的功能逻辑部分进行多次测试，并用不同的测试数据进行多次测试，同时建议对合约的安全性进行安全审计，合约开发没小事，
62430发布于 2021-07-21 - 来自专栏字节脉搏实验室
智能合约安全审计之路-随机误用漏洞
描叙： 智能合约开发中，在程序中使用随机数较好的伪随机数是很难的。很多看似无法被预言的随机数种子或变量，实际被预言的难度很低。 核心问题：一旦在智能合约中使用了随机性很差的随机数作为关键变量，就面临着随机数被预言的攻击风险。 ? 一些概念 智能合约常用的随机数计算方式 keccak256(seed) 常用seed的选取： 私有变量 区块有关状态block.something msg.sender 上述数据的哈希或者运算组合 ? ，其不安全在于，这些数据对于同一个transaction中的合约调用是可预测的。 msg.sender随机预测 使用msg.sender做为随机数种子的安全风险在于，该数据是用户可控的。若随机数种子一旦可以被攻击者选择或控制，就会使随机数面临被预测的风险。
1.3K10发布于 2020-04-21 - 来自专栏Gcow安全团队
智能合约安全审计之路-整数溢出漏洞
描述：变量在参与运算的过程中，运算结果超出了变量类型所能表示的范围，导致实际存储的计算结果出错 核心问题：非预期的整数溢出将导致智能合约运行出错，影响合约的可靠性和安全性 基础知识 整数溢出的分类 整数上溢 漏洞合约分析 pragma solidity ^0.4.24; contract IntOverflow{ function addNumber(uint a, uint b) public
49010发布于 2020-03-19 - 来自专栏深入浅出区块链技术
101项智能合约安全检查清单
其结果是利用智能合约漏洞把资金耗尽，从而降低人们对这个未来无信任的去中心化基础设施的信任。因此，智能合约专家也需要检查清单。 本篇文章从不同来源整理了 101 个智能合约安全陷阱和最佳实践的清单。 我相信这份方便的 "安全智能合约检查清单 "将有助于开发者/审核员在以太坊上使用 Solidity 构建更安全和稳健的智能合约。 智能合约安全检查清单 Solidity 版本。 代理合约中的覆盖函数防止逻辑合约中的函数被调用。(见此处[132]) 总结 这篇文章从广泛引用的资料中整理了 101 个基本智能合约安全陷阱和最佳实践的清单。 智能合约开发者/审核员/协议的安全负担是巨大的。 检查清单有助于减少这种认知负荷，并可以帮助在以太坊上构建更安全和稳健的智能合约。 我希望你觉得这有些用处。感谢您的阅读，期待你的评论和反馈。
2.1K10发布于 2021-03-16 - 来自专栏字节脉搏实验室
智能合约安全审计之路-访问控制漏洞
描述：合约没有设置合理的访问控制模型，以及没有对合约有效的校验导致访问控制漏洞的发生 核心问题：public的恶意使用(本次案例合约为例) ? 漏洞描述 智能合约的访问控制漏洞主要体现在以下俩个方面: 代码层面可见性 针对函数和变量，限制其所能被修改和调用的作用域 逻辑层面权限约束 通常针对函数，限制某些特权用户访问 代码层面可见性的函数普及: public 默认状态下，可以进行任何形式的调用 external 可以通过其他合约或者交易来调用，不能在合约内部进行调用 internal 只能在合约(含子合约)内部进行调用 private 只能在合约 编译完成后会出现1个合约为AccessGame 首先部署AccessGame(漏洞合约)，Account设置默认管理员地址(0Xca3…a733c),点击Deploy，部署完成后，首先点击owner,查看管理员为 漏洞预防 设计合理的访问控制模型,并在代码中进行校验 合理使用可见性约束和modifier 使用形式化验证检测智能合约的访问控制漏洞 ?
1.4K20发布于 2020-03-08
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号