Msg.sender.send(msg.value)安全吗？

Question

在我的智能契约中使用这一行代码时，是否存在某种类型的重入攻击？

Answer 1

msg.sender可靠地是调用该函数的直接、最内部的发送方。这可能是另一份合同，所以不一定是签字人启动了交易。希望前面的内容不会混淆它的可靠性。它能可靠地完成它应该做的事情。

msg.value可靠地表示发送到该函数的以太数量。它不包括天然气，这是一个单独的问题。在连锁合同的情况下。不是签字人寄来的钱。是资金到达了这个功能。打电话的人必须设法把资金转到另一份合同上。

该声明本身将发挥预期的作用，它将发送2300个气体(津贴)，这不足以发动重新进入攻击。2,300只足以发出一个事件，但不足以更新状态，无论在回退函数中发生了什么，剩下的不足2,300个。断路器取决于价格，而不是代码逻辑。最好依靠合理的逻辑。

重新进入防御依赖于你解决某些问题的命令，所以不管你发送了多少气体，或者接收者对它做了什么。检查检查-效果-交互作用：https://solidity.readthedocs.io/en/v0.4.24/security-considerations.html

1. 支票:这个交易可以接受吗？认真地考虑revert/require在不可接受的请求情况下“很难失败”。这通常是正确的做法。
2. 效果:现在，做所有的簿记，状态更新，事件等乐观。在将流控制转移到不受信任的合同之前，这会使您的房子井然有序。
3. 交互:最后，与call、send或transfer交互。这应该是函数做的最后一件事。如果这碰巧失败了，那么您需要恢复步骤2中所做的所有操作。如果您使用transfer，则自动恢复。如果不检查返回bool (成功吗？)，编译器将发出抱怨。来自send或call。

如果这些担忧被无序处理，那么Reentance攻击是有可能的。

同样值得考虑的是：

send通常是错误的选择。考虑一下transfer。如果相当于：

require(msg.sender.send(msg.value)); // silences the unchecked return value complaint

我们为什么要这么做？一定有原因。假设只允许成员玩，这就是为什么我们想要还钱。

require(isMember(msg.sender), "You are not a member."); // fail hard

由于require恢复，对于非成员，整个事务必须失败。虽然总是有例外，但这是一个很好的默认方法。

希望能帮上忙。