Vulnerability principle
One of the features of Ethereum smart contracts is the ability to call and use the code of other external contracts. These contracts typically operate on ether, often sending ether to various external user addresses. This operation of calling an external contract or sending Ether to an external address requires the contract to submit an external call. These external calls can be hijacked by an attacker, for example, via a fallback function, forcing the contract to execute further code, including calls to itself. In this way, the code can enter the contract repeatedly, which is the origin of "Re-Entrancy". This type of vulnerability was exploited in the famous DAO hacking incident.
The following Solidity knowledge points can help us better understand the underlying causes of reentrancy attacks.
Fallback function
A contract can have an unnamed function. This function cannot have parameters or return values. If in a call to the contract, no other function matches the given function identifier (or no call data is provided), then this function (fallback function) will be executed.
In addition to this, every time the contract receives ether (without any data), this function will be executed. Additionally, in order to receive ether, the fallback function must be marked as payable. If no such function exists, the contract cannot receive ether through regular transactions.
A contract that does not define a fallback function and receives Ether directly (without a function call, that is, using sendor transfer) will throw an exception and return Ether. So if you want your contract to receive ether, you must implement the fallback function.
Furthermore, a contract cannot react to such ether transfers and therefore cannot reject them. This is a decision made when the EVM was designed, and Solidity cannot get around this problem.
Call function call
In Solidity, the call function family