{"id":19915561,"url":"https://github.com/demining/improving-overall-security","last_synced_at":"2025-09-19T02:33:14.456Z","repository":{"id":144620943,"uuid":"615042939","full_name":"demining/Improving-Overall-Security","owner":"demining","description":"Improving the overall security of the ecosystem from attacks on smart contracts","archived":false,"fork":false,"pushed_at":"2023-03-16T20:54:07.000Z","size":1098,"stargazers_count":4,"open_issues_count":0,"forks_count":1,"subscribers_count":2,"default_branch":"main","last_synced_at":"2024-11-12T21:44:21.389Z","etag":null,"topics":["blockchain","blockchain-technology","cryptocurrency","ecosystem","smartcontract","smartcontracts"],"latest_commit_sha":null,"homepage":"https://cryptodeeptech.ru/improving-overall-security/","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/demining.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-03-16T20:47:41.000Z","updated_at":"2024-08-12T20:30:17.000Z","dependencies_parsed_at":null,"dependency_job_id":"9cb96b5a-56c3-4a68-8aad-4a8d89e70a9b","html_url":"https://github.com/demining/Improving-Overall-Security","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/demining%2FImproving-Overall-Security","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/demining%2FImproving-Overall-Security/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/demining%2FImproving-Overall-Security/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/demining%2FImproving-Overall-Security/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/demining","download_url":"https://codeload.github.com/demining/Improving-Overall-Security/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":233547199,"owners_count":18692359,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blockchain","blockchain-technology","cryptocurrency","ecosystem","smartcontract","smartcontracts"],"created_at":"2024-11-12T21:40:58.594Z","updated_at":"2025-09-19T02:33:08.914Z","avatar_url":"https://github.com/demining.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n\n# Improving the overall security of the ecosystem from attacks on smart contracts\n\n---\n\n\n---\n\n\n\n\n\n\n\u003cfigure class=\"aligncenter size-large\"\u003e\u003cimg decoding=\"async\" width=\"1024\" height=\"576\" src=\"./Improving the overall security of the ecosystem from attacks on smart contracts - CRYPTO DEEP TECH_files/035-1024x576.png\" alt=\"Improving the overall security of the ecosystem from attacks on smart contracts\" class=\"wp-image-1996\" srcset=\"https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-1024x576.png 1024w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-300x169.png 300w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-768x432.png 768w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035.png 1280w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\u003e\u003c/figure\u003e\u003c/div\u003e\n\n\n---\n\n\n* Tutorial: https://youtu.be/HVh_cbsgSMg\n* Tutorial: https://cryptodeeptech.ru/improving-overall-security\n\n\n---\n\n\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003cp\u003e\u003c/p\u003e\n\n\n\n\u003ch2\u003eFront-Running AKA Transaction-Ordering Dependence\u003c/h2\u003e\n\n\n\n\u003cp\u003eThe University of Concordia considers front-running to be, “a course of action where an entity benefits from prior access to privileged market information about upcoming transactions and trades.” This knowledge of future events in a market can lead to exploitation.\u003c/p\u003e\n\n\n\n\u003cp\u003eFor example, knowing that a very large purchase of a specific token is going to occur, a bad actor can purchase that token in advance, and sell the token for a profit when the oversized buy order increases the price.\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003ca href=\"https://cryptodeeptech.ru/blockchain-attack-vectors/\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eFront-running attacks have long been an issue in financial markets, and due to blockchain’s transparent nature, the problem is coming up again in cryptocurrency markets.\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003eSince the solution to this problem varies on a per contract basis, it can be hard to protect against. Possible solutions include batching transactions and using a pre-commit scheme, i.e. allow users to submit details at a later time.\u003c/p\u003e\n\n\n\n\u003cp class=\"has-text-align-center has-medium-font-size\"\u003e\u003ca href=\"https://cryptodeep.ru/doc/SoK_Transparent_Dishonesty_Front-Running_Attacks_on_Blockchain.pdf\" target=\"_blank\" rel=\"noreferrer noopener\"\u003e\u003cstrong\u003ePDF:  SoK: Transparent Dishonesty: Front-Running Attacks on Blockchain\u003c/strong\u003e\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003ch1\u003eFrontrunning\u003c/h1\u003e\n\n\n\n\u003cp\u003eSince all transactions are visible in the mempool for a short while before being executed, observers of the network can see and react to an action before it is included in a block. An example of how this can be exploited is with a decentralized exchange where a buy order transaction can be seen, and second order can be broadcast and executed before the first transaction is included. Protecting against this is difficult, as it would come down to the specific contract itself.\u003c/p\u003e\n\n\n\n\u003cp\u003eFront-running, coined originally for traditional financial markets, is the race to order the chaos to the winner’s benefit. In financial markets, the flow of information gave birth to intermediaries that could simply profit by being the first to know and react to some information. These attacks mostly had been within stock market deals and early domain registries, such as whois gateways.\u003c/p\u003e\n\n\n\n\u003cp\u003efront-run·ning (/ˌfrəntˈrəniNG/)\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003cem\u003enoun\u003c/em\u003e: front-running;\u003c/p\u003e\n\n\n\n\u003col\u003e\n\u003cli\u003e\u003cem\u003eSTOCK MARKET\u003c/em\u003ethe practice by market makers of dealing on advance information provided by their brokers and investment analysts, before their clients have been given the information.\u003c/li\u003e\n\u003c/ol\u003e\n\n\n\n\u003ch3 id=\"taxonomy\"\u003eTaxonomy\u003c/h3\u003e\n\n\n\n\u003cp\u003eBy defining a\u0026nbsp;\u003ca href=\"https://arxiv.org/abs/1902.05164\"\u003etaxonomy\u003c/a\u003e\u0026nbsp;and differentiating each group from another, we can make it easier to discuss the problem and find solutions for each group.\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003ca href=\"https://cryptodeeptech.ru/blockchain-attack-vectors/\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eWe define the following categories of front-running attacks\u003c/a\u003e:\u003c/p\u003e\n\n\n\n\u003col\u003e\n\u003cli\u003eDisplacement\u003c/li\u003e\n\n\n\n\u003cli\u003eInsertion\u003c/li\u003e\n\n\n\n\u003cli\u003eSuppression\u003c/li\u003e\n\u003c/ol\u003e\n\n\n\n\u003ch4 id=\"displacement\"\u003eDisplacement\u003c/h4\u003e\n\n\n\n\u003cp\u003eIn the first type of attack,\u0026nbsp;\u003cem\u003ea displacement attack\u003c/em\u003e, it is\u0026nbsp;\u003cstrong\u003enot important\u003c/strong\u003e\u0026nbsp;for Alice’s (User) function call to run after Mallory (Adversary) runs her function. Alice’s can be orphaned or run with no meaningful effect. Examples of displacement include:\u003c/p\u003e\n\n\n\n\u003cul\u003e\n\u003cli\u003eAlice trying to register a domain name and Mallory registering it first;\u003c/li\u003e\n\n\n\n\u003cli\u003eAlice trying to submit a bug to receive a bounty and Mallory stealing it and submitting it first;\u003c/li\u003e\n\n\n\n\u003cli\u003eAlice trying to submit a bid in an auction and Mallory copying it.\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\n\u003cp\u003eThis attack is commonly performed by increasing the\u0026nbsp;\u003ccode\u003egasPrice\u003c/code\u003e\u0026nbsp;higher than network average, often by a multiplier of 10 or more.\u003c/p\u003e\n\n\n\n\u003ch4 id=\"insertion\"\u003eInsertion\u003c/h4\u003e\n\n\n\n\u003cp\u003eFor this type of attack, it is\u0026nbsp;\u003cstrong\u003eimportant\u003c/strong\u003e\u0026nbsp;to the adversary that the original function call runs after her transaction. In an insertion attack, after Mallory runs her function, the state of the contract is changed and she needs Alice’s original function to run on this modified state. For example, if Alice places a purchase order on a blockchain asset at a higher price than the best offer, Mallory will insert two transactions: she will purchase at the best offer price and then offer the same asset for sale at Alice’s slightly higher purchase price. If Alice’s transaction is then run after, Mallory will profit on the price difference without having to hold the asset.\u003c/p\u003e\n\n\n\n\u003cp\u003eAs with displacement attacks, this is usually done by outbidding Alice’s transaction in the gas price auction.\u003c/p\u003e\n\n\n\n\u003cp\u003eTransaction Order Dependence\u003c/p\u003e\n\n\n\n\u003cp\u003eTransaction Order Dependence is equivalent to race condition in smart contracts. An example, if one function sets the reward percentage, and the withdraw function uses that percentage; then withdraw transaction can be front-run by a change reward function call, which impacts the amount that will be withdrawn eventually.\u003c/p\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-114\"\u003eSWC-114\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003ch4 id=\"suppression\"\u003eSuppression\u003c/h4\u003e\n\n\n\n\u003cp\u003eIn a suppression attack, a.k.a\u0026nbsp;\u003cem\u003eBlock Stuffing\u003c/em\u003e\u0026nbsp;attacks, after Mallory runs her function, she tries to delay Alice from running her function.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis was the case with the first winner of the “Fomo3d” game and some other on-chain hacks. The attacker sent multiple transactions with a high\u0026nbsp;\u003ccode\u003egasPrice\u003c/code\u003e\u0026nbsp;and\u0026nbsp;\u003ccode\u003egasLimit\u003c/code\u003e\u0026nbsp;to custom smart contracts that assert (or use other means) to consume all the gas and fill up the block’s\u0026nbsp;\u003ccode\u003egasLimit\u003c/code\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eVariants\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003ca href=\"https://cryptodeeptech.ru/blockchain-attack-vectors/\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eEach of these attacks has two variants,\u0026nbsp;\u003cem\u003easymmetric\u003c/em\u003e\u0026nbsp;and\u0026nbsp;\u003cem\u003ebulk\u003c/em\u003e.\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003eIn some cases, Alice and Mallory are performing different operations. For example, Alice is trying to cancel an offer, and Mallory is trying to fulfill it first. We call this\u0026nbsp;\u003cem\u003easymmetric displacement\u003c/em\u003e. In other cases, Mallory is trying to run a large set of functions: for example, Alice and others are trying to buy a limited set of shares offered by a firm on a blockchain. We call this\u0026nbsp;\u003cem\u003ebulk displacement\u003c/em\u003e.\u003c/p\u003e\n\n\n\n\u003ch3 id=\"mitigations\"\u003eMitigations\u003c/h3\u003e\n\n\n\n\u003cp\u003eFront-running is a pervasive issue on public blockchains such as Ethereum.\u003c/p\u003e\n\n\n\n\u003cp\u003eThe best remediation is to\u0026nbsp;\u003cstrong\u003eremove the benefit of front-running in your application\u003c/strong\u003e, mainly by removing the importance of transaction ordering or time. For example, in markets, it would be better to implement batch auctions (this also protects against high-frequency trading concerns). Another way is to use a pre-commit scheme (“I’m going to submit the details later”). A third option is to mitigate the cost of front-running by specifying a maximum or minimum acceptable price range on a trade, thereby limiting price slippage.\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003cstrong\u003eTransaction Ordering:\u003c/strong\u003e\u0026nbsp;Go-Ethereum (Geth) nodes order the transactions based on their\u0026nbsp;\u003ccode\u003egasPrice\u003c/code\u003e\u0026nbsp;and address nonce. This, however, results in a gas auction between participants in the network to get included in the block currently being mined.\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003cstrong\u003eConfidentiality:\u003c/strong\u003e\u0026nbsp;Another approach is to limit the visibility of the transactions, this can be done using a “commit and reveal” scheme.\u003c/p\u003e\n\n\n\n\u003cp\u003eA simple implementation is to store the keccak256 hash of the data in the first transaction, then reveal the data and verify it against the hash in the second transaction. However note that the transaction itself leaks the intention and possibly the value of the collateralization. There are enhanced commit and reveal schemes that are more secure, however require more transactions to function, e.g.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch2\u003eDoS with Block Gas Limit\u003c/h2\u003e\n\n\n\n\u003cp\u003eIn the Ethereum blockchain, the blocks all have a gas limit. One of the benefits of a block gas limit is that it prevents attackers from creating an infinite transaction loop, but if the gas usage of a transaction exceeds this limit, the transaction will fail. This can lead to a DoS attack in a couple different ways.\u003c/p\u003e\n\n\n\n\u003ch3\u003e\u003ca href=\"https://github.com/allpaca/smart-contract-attack-vectors/blob/master/attacks/dos-gas-limit.md#unbounded-operations\"\u003e\u003c/a\u003eUnbounded Operations\u003c/h3\u003e\n\n\n\n\u003cp\u003eA situation in which the block gas limit can be an issue is in sending funds to an array of addresses. Even without any malicious intent, this can easily go wrong. Just by having too large an array of users to pay can max out the gas limit and prevent the transaction from ever succeeding.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis situation can also lead to an attack. Say a bad actor decides to create a significant amount of addresses, with each address being paid a small amount of funds from the smart contract. If done effectively, the transaction can be blocked indefinitely, possibly even preventing further transactions from going through.\u003c/p\u003e\n\n\n\n\u003cp\u003eAn effective solution to this problem would be to use a pull payment system over the current push payment system. To do this, separate each payment into it’s own transaction, and have the recipient call the function.\u003c/p\u003e\n\n\n\n\u003cp\u003eIf, for some reason, you really need to loop through an array of unspecified length, at least expect it to potentially take multiple blocks, and allow it to be performed in multiple transactions – as seen in this example:\u003c/p\u003e\n\n\n\n\u003cpre class=\"wp-block-code\"\u003e\u003ccode\u003estruct Payee {\n    address addr;\n    uint256 value;\n}\n\nPayee[] payees;\nuint256 nextPayeeIndex;\n\nfunction payOut() {\n    uint256 i = nextPayeeIndex;\n    while (i \u0026lt; payees.length \u0026amp;\u0026amp; msg.gas \u0026gt; 200000) {\n      payees[i].addr.send(payees[i].value);\n      i++;\n    }\n    nextPayeeIndex = i;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003ch3\u003e\u003ca href=\"https://github.com/allpaca/smart-contract-attack-vectors/blob/master/attacks/dos-gas-limit.md#block-stuffing\"\u003e\u003c/a\u003eBlock Stuffing\u003c/h3\u003e\n\n\n\n\u003cp\u003eIn some situations, your contract can be attacked with a block gas limit even if you don’t loop through an array of unspecified length. An attacker can fill several blocks before a transaction can be processed by using a sufficiently high gas price.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis attack is done by issuing several transactions at a very high gas price. If the gas price is high enough, and the transactions consume enough gas, they can fill entire blocks and prevent other transactions from being processed.\u003c/p\u003e\n\n\n\n\u003cp\u003eEthereum transactions require the sender to pay gas to disincentivize spam attacks, but in some situations, there can be enough incentive to go through with such an attack. For example, a block stuffing attack was used on a gambling Dapp, Fomo3D. The app had a countdown timer, and users could win a jackpot by being the last to purchase a key, except everytime a user bought a key, the timer would be extended. An attacker bought a key then stuffed the next 13 blocks and a row so they could win the jackpot.\u003c/p\u003e\n\n\n\n\u003cp\u003eT\u003ca href=\"https://cryptodeeptech.ru/blockchain-attack-vectors/\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eo prevent such attacks from occuring, it’s important to carefully consider whether it’s safe to incorporate time-based actions in your application.\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003ch1\u003eDenial of Service\u003c/h1\u003e\n\n\n\n\u003ch2 id=\"dos-with-unexpected-revert\"\u003eDoS with (Unexpected) revert\u003c/h2\u003e\n\n\n\n\u003cp\u003eConsider a simple auction contract:\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_1\" class=\"wp-block-code\"\u003e\u003ccode\u003e// INSECURE\ncontract Auction {\n    address currentLeader;\n    uint highestBid;\n\n    function bid() payable {\n        require(msg.value \u0026gt; highestBid);\n\n        require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert\n\n        currentLeader = msg.sender;\n        highestBid = msg.value;\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eIf attacker bids using a smart contract which has a fallback function that reverts any payment, the attacker can win any auction. When it tries to refund the old leader, it reverts if the refund fails. This means that a malicious bidder can become the leader while making sure that any refunds to their address will\u0026nbsp;\u003cem\u003ealways\u003c/em\u003e\u0026nbsp;fail. In this way, they can prevent anyone else from calling the\u0026nbsp;\u003ccode\u003ebid()\u003c/code\u003e\u0026nbsp;function, and stay the leader forever. A recommendation is to set up a\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003epull payment system\u003c/a\u003e\u0026nbsp;instead, as described earlier.\u003c/p\u003e\n\n\n\n\u003cp\u003eAnother example is when a contract may iterate through an array to pay users (e.g., supporters in a crowdfunding contract). It’s common to want to make sure that each payment succeeds. If not, one should revert. The issue is that if one call fails, you are reverting the whole payout system, meaning the loop will never complete. No one gets paid because one address is forcing an error.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_2\" class=\"wp-block-code\"\u003e\u003ccode\u003eaddress[] private refundAddresses;\nmapping (address =\u0026gt; uint) public refunds;\n\n// bad\nfunction refundAll() public {\n    for(uint x; x \u0026lt; refundAddresses.length; x++) { // arbitrary length iteration based on how many addresses participated\n        require(refundAddresses[x].send(refunds[refundAddresses[x]])) // doubly bad, now a single failure on send will hold up all funds\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eAgain, the recommended solution is to\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003efavor pull over push payments\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-113\"\u003eSWC-113\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003ch2 id=\"dos-with-block-gas-limit\"\u003eDoS with Block Gas Limit\u003c/h2\u003e\n\n\n\n\u003cp\u003eEach block has an upper bound on the amount of gas that can be spent, and thus the amount computation that can be done. This is the Block Gas Limit. If the gas spent exceeds this limit, the transaction will fail. This leads to a couple of possible Denial of Service vectors:\u003c/p\u003e\n\n\n\n\u003ch3 id=\"gas-limit-dos-on-a-contract-via-unbounded-operations\"\u003eGas Limit DoS on a Contract via Unbounded Operations\u003c/h3\u003e\n\n\n\n\u003cp\u003eYou may have noticed another problem with the previous example: by paying out to everyone at once, you risk running into the block gas limit.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis can lead to problems even in the absence of an intentional attack. However, it’s especially bad if an attacker can manipulate the amount of gas needed. In the case of the previous example, the attacker could add a bunch of addresses, each of which needs to get a very small refund. The gas cost of refunding each of the attacker’s addresses could, therefore, end up being more than the gas limit, blocking the refund transaction from happening at all.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis is another reason to\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003efavor pull over push payments\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions. You will need to keep track of how far you’ve gone, and be able to resume from that point, as in the following example:\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_3\" class=\"wp-block-code\"\u003e\u003ccode\u003estruct Payee {\n    address addr;\n    uint256 value;\n}\n\nPayee[] payees;\nuint256 nextPayeeIndex;\n\nfunction payOut() {\n    uint256 i = nextPayeeIndex;\n    while (i \u0026lt; payees.length \u0026amp;\u0026amp; gasleft() \u0026gt; 200000) {\n      payees[i].addr.send(payees[i].value);\n      i++;\n    }\n    nextPayeeIndex = i;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eYou will need to make sure that nothing bad will happen if other transactions are processed while waiting for the next iteration of the\u0026nbsp;\u003ccode\u003epayOut()\u003c/code\u003e\u0026nbsp;function. So only use this pattern if absolutely necessary.\u003c/p\u003e\n\n\n\n\u003ch3 id=\"gas-limit-dos-on-the-network-via-block-stuffing\"\u003eGas Limit DoS on the Network via Block Stuffing\u003c/h3\u003e\n\n\n\n\u003cp\u003eEven if your contract does not contain an unbounded loop, an attacker can prevent other transactions from being included in the blockchain for several blocks by placing computationally intensive transactions with a high enough gas price.\u003c/p\u003e\n\n\n\n\u003cp\u003eTo do this, the attacker can issue several transactions which will consume the entire gas limit, with a high enough gas price to be included as soon as the next block is mined. No gas price can guarantee inclusion in the block, but the higher the price is, the higher is the chance.\u003c/p\u003e\n\n\n\n\u003cp\u003eIf the attack succeeds, no other transactions will be included in the block. Sometimes, an attacker’s goal is to block transactions to a specific contract prior to specific time.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis attack\u0026nbsp;\u003ca href=\"https://solmaz.io/2018/10/18/anatomy-block-stuffing/\"\u003ewas conducted\u003c/a\u003e\u0026nbsp;on Fomo3D, a gambling app. The app was designed to reward the last address that purchased a “key”. Each key purchase extended the timer, and the game ended once the timer went to 0. The attacker bought a key and then stuffed 13 blocks in a row until the timer was triggered and the payout was released. Transactions sent by attacker took 7.9 million gas on each block, so the gas limit allowed a few small “send” transactions (which take 21,000 gas each), but disallowed any calls to the\u0026nbsp;\u003ccode\u003ebuyKey()\u003c/code\u003e\u0026nbsp;function (which costs 300,000+ gas).\u003c/p\u003e\n\n\n\n\u003cp\u003eA Block Stuffing attack can be used on any contract requiring an action within a certain time period. However, as with any attack, it is only profitable when the expected reward exceeds its cost. The cost of this attack is directly proportional to the number of blocks which need to be stuffed. If a large payout can be obtained by preventing actions from other participants, your contract will likely be targeted by such an attack.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch2\u003eDoS with (Unexpected) revert\u003c/h2\u003e\n\n\n\n\u003cp\u003eDoS (Denial of Service) attacks can occur in functions when you try to send funds to a user and the functionality relies on that fund transfer being successful.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis can be problematic in the case that the funds are sent to a smart contract created by a bad actor, since they can simply create a fallback function that reverts all payments.\u003c/p\u003e\n\n\n\n\u003cp\u003eFor example:\u003c/p\u003e\n\n\n\n\u003cpre class=\"wp-block-code\"\u003e\u003ccode\u003e// INSECURE\ncontract Auction {\n    address currentLeader;\n    uint highestBid;\n\n    function bid() payable {\n        require(msg.value \u0026gt; highestBid);\n\n        require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert\n\n        currentLeader = msg.sender;\n        highestBid = msg.value;\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eAs you can see in this example, if an attacker bids from a smart contract with a fallback function reverting all payments, they can never be refunded, and thus no one can ever make a higher bid.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis can also be problematic without an attacker present. For example, you may want to pay an array of users by iterating through the array, and of course you would want to make sure each user is properly paid. The problem here is that if one payment fails, the funtion is reverted and no one is paid.\u003c/p\u003e\n\n\n\n\u003cpre class=\"wp-block-code\"\u003e\u003ccode\u003eaddress[] private refundAddresses;\nmapping (address =\u0026gt; uint) public refunds;\n\n// bad\nfunction refundAll() public {\n    for(uint x; x \u0026lt; refundAddresses.length; x++) { // arbitrary length iteration based on how many addresses participated\n        require(refundAddresses[x].send(refunds[refundAddresses[x]])) // doubly bad, now a single failure on send will hold up all funds\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eAn effective solution to this problem would be to use a pull payment system over the current push payment system. To do this, separate each payment into it’s own transaction, and have the recipient call the function.\u003c/p\u003e\n\n\n\n\u003cpre class=\"wp-block-code\"\u003e\u003ccode\u003econtract auction {\n    address highestBidder;\n    uint highestBid;\n    mapping(address =\u0026gt; uint) refunds;\n\n    function bid() payable external {\n        require(msg.value \u0026gt;= highestBid);\n\n        if (highestBidder != address(0)) {\n            refunds[highestBidder] += highestBid; // record the refund that this user can claim\n        }\n\n        highestBidder = msg.sender;\n        highestBid = msg.value;\n    }\n\n    function withdrawRefund() external {\n        uint refund = refunds[msg.sender];\n        refunds[msg.sender] = 0;\n        (bool success, ) = msg.sender.call.value(refund)(\"\");\n        require(success);\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch1\u003eDenial of Service\u003c/h1\u003e\n\n\n\n\u003ch2 id=\"dos-with-unexpected-revert\"\u003eDoS with (Unexpected) revert\u003c/h2\u003e\n\n\n\n\u003cp\u003eConsider a simple auction contract:\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_1\" class=\"wp-block-code\"\u003e\u003ccode\u003e// INSECURE\ncontract Auction {\n    address currentLeader;\n    uint highestBid;\n\n    function bid() payable {\n        require(msg.value \u0026gt; highestBid);\n\n        require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert\n\n        currentLeader = msg.sender;\n        highestBid = msg.value;\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eIf attacker bids using a smart contract which has a fallback function that reverts any payment, the attacker can win any auction. When it tries to refund the old leader, it reverts if the refund fails. This means that a malicious bidder can become the leader while making sure that any refunds to their address will\u0026nbsp;\u003cem\u003ealways\u003c/em\u003e\u0026nbsp;fail. In this way, they can prevent anyone else from calling the\u0026nbsp;\u003ccode\u003ebid()\u003c/code\u003e\u0026nbsp;function, and stay the leader forever. A recommendation is to set up a\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003epull payment system\u003c/a\u003e\u0026nbsp;instead, as described earlier.\u003c/p\u003e\n\n\n\n\u003cp\u003eAnother example is when a contract may iterate through an array to pay users (e.g., supporters in a crowdfunding contract). It’s common to want to make sure that each payment succeeds. If not, one should revert. The issue is that if one call fails, you are reverting the whole payout system, meaning the loop will never complete. No one gets paid because one address is forcing an error.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_2\" class=\"wp-block-code\"\u003e\u003ccode\u003eaddress[] private refundAddresses;\nmapping (address =\u0026gt; uint) public refunds;\n\n// bad\nfunction refundAll() public {\n    for(uint x; x \u0026lt; refundAddresses.length; x++) { // arbitrary length iteration based on how many addresses participated\n        require(refundAddresses[x].send(refunds[refundAddresses[x]])) // doubly bad, now a single failure on send will hold up all funds\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eAgain, the recommended solution is to\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003efavor pull over push payments\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-113\"\u003eSWC-113\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003ch2 id=\"dos-with-block-gas-limit\"\u003eDoS with Block Gas Limit\u003c/h2\u003e\n\n\n\n\u003cp\u003eEach block has an upper bound on the amount of gas that can be spent, and thus the amount computation that can be done. This is the Block Gas Limit. If the gas spent exceeds this limit, the transaction will fail. This leads to a couple of possible Denial of Service vectors:\u003c/p\u003e\n\n\n\n\u003ch3 id=\"gas-limit-dos-on-a-contract-via-unbounded-operations\"\u003eGas Limit DoS on a Contract via Unbounded Operations\u003c/h3\u003e\n\n\n\n\u003cp\u003eYou may have noticed another problem with the previous example: by paying out to everyone at once, you risk running into the block gas limit.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis can lead to problems even in the absence of an intentional attack. However, it’s especially bad if an attacker can manipulate the amount of gas needed. In the case of the previous example, the attacker could add a bunch of addresses, each of which needs to get a very small refund. The gas cost of refunding each of the attacker’s addresses could, therefore, end up being more than the gas limit, blocking the refund transaction from happening at all.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis is another reason to\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/\"\u003efavor pull over push payments\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions. You will need to keep track of how far you’ve gone, and be able to resume from that point, as in the following example:\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_3\" class=\"wp-block-code\"\u003e\u003ccode\u003estruct Payee {\n    address addr;\n    uint256 value;\n}\n\nPayee[] payees;\nuint256 nextPayeeIndex;\n\nfunction payOut() {\n    uint256 i = nextPayeeIndex;\n    while (i \u0026lt; payees.length \u0026amp;\u0026amp; gasleft() \u0026gt; 200000) {\n      payees[i].addr.send(payees[i].value);\n      i++;\n    }\n    nextPayeeIndex = i;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eYou will need to make sure that nothing bad will happen if other transactions are processed while waiting for the next iteration of the\u0026nbsp;\u003ccode\u003epayOut()\u003c/code\u003e\u0026nbsp;function. So only use this pattern if absolutely necessary.\u003c/p\u003e\n\n\n\n\u003ch3 id=\"gas-limit-dos-on-the-network-via-block-stuffing\"\u003eGas Limit DoS on the Network via Block Stuffing\u003c/h3\u003e\n\n\n\n\u003cp\u003eEven if your contract does not contain an unbounded loop, an attacker can prevent other transactions from being included in the blockchain for several blocks by placing computationally intensive transactions with a high enough gas price.\u003c/p\u003e\n\n\n\n\u003cp\u003eTo do this, the attacker can issue several transactions which will consume the entire gas limit, with a high enough gas price to be included as soon as the next block is mined. No gas price can guarantee inclusion in the block, but the higher the price is, the higher is the chance.\u003c/p\u003e\n\n\n\n\u003cp\u003eIf the attack succeeds, no other transactions will be included in the block. Sometimes, an attacker’s goal is to block transactions to a specific contract prior to specific time.\u003c/p\u003e\n\n\n\n\u003cp\u003eThis attack\u0026nbsp;\u003ca href=\"https://solmaz.io/2018/10/18/anatomy-block-stuffing/\"\u003ewas conducted\u003c/a\u003e\u0026nbsp;on Fomo3D, a gambling app. The app was designed to reward the last address that purchased a “key”. Each key purchase extended the timer, and the game ended once the timer went to 0. The attacker bought a key and then stuffed 13 blocks in a row until the timer was triggered and the payout was released. Transactions sent by attacker took 7.9 million gas on each block, so the gas limit allowed a few small “send” transactions (which take 21,000 gas each), but disallowed any calls to the\u0026nbsp;\u003ccode\u003ebuyKey()\u003c/code\u003e\u0026nbsp;function (which costs 300,000+ gas).\u003c/p\u003e\n\n\n\n\u003cp\u003eA Block Stuffing attack can be used on any contract requiring an action within a certain time period. However, as with any attack, it is only profitable when the expected reward exceeds its cost. The cost of this attack is directly proportional to the number of blocks which need to be stuffed. If a large payout can be obtained by preventing actions from other participants, your contract will likely be targeted by such an attack.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch1\u003eExternal Calls\u003c/h1\u003e\n\n\n\n\u003ch4 id=\"use-caution-when-making-external-calls\"\u003eUse caution when making external calls\u003c/h4\u003e\n\n\n\n\u003cp\u003eCalls to untrusted contracts can introduce several unexpected risks or errors. External calls may execute malicious code in that contract\u0026nbsp;\u003cem\u003eor\u003c/em\u003e\u0026nbsp;any other contract that it depends upon. As such, every external call should be treated as a potential security risk. When it is not possible, or undesirable to remove external calls, use the recommendations in the rest of this section to minimize the danger.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"mark-untrusted-contracts\"\u003eMark untrusted contracts\u003c/h4\u003e\n\n\n\n\u003cp\u003eWhen interacting with external contracts, name your variables, methods, and contract interfaces in a way that makes it clear that interacting with them is potentially unsafe. This applies to your own functions that call external contracts.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_1\" class=\"wp-block-code\"\u003e\u003ccode\u003e// bad\nBank.withdraw(100); // Unclear whether trusted or untrusted\n\nfunction makeWithdrawal(uint amount) { // Isn't clear that this function is potentially unsafe\n    Bank.withdraw(amount);\n}\n\n// good\nUntrustedBank.withdraw(100); // untrusted external call\nTrustedBank.withdraw(100); // external but trusted bank contract maintained by XYZ Corp\n\nfunction makeUntrustedWithdrawal(uint amount) {\n    UntrustedBank.withdraw(amount);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"avoid-state-changes-after-external-calls\"\u003eAvoid state changes after external calls\u003c/h4\u003e\n\n\n\n\u003cp\u003eWhether using\u0026nbsp;\u003cem\u003eraw calls\u003c/em\u003e\u0026nbsp;(of the form\u0026nbsp;\u003ccode\u003esomeAddress.call()\u003c/code\u003e) or\u0026nbsp;\u003cem\u003econtract calls\u003c/em\u003e\u0026nbsp;(of the form\u0026nbsp;\u003ccode\u003eExternalContract.someMethod()\u003c/code\u003e), assume that malicious code might execute. Even if\u0026nbsp;\u003ccode\u003eExternalContract\u003c/code\u003e\u0026nbsp;is not malicious, malicious code can be executed by any contracts\u0026nbsp;\u003cem\u003eit\u003c/em\u003e\u0026nbsp;calls.\u003c/p\u003e\n\n\n\n\u003cp\u003eOne particular danger is malicious code may hijack the control flow, leading to vulnerabilities due to reentrancy. (See\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/\"\u003eReentrancy\u003c/a\u003e\u0026nbsp;for a fuller discussion of this problem).\u003c/p\u003e\n\n\n\n\u003cp\u003eIf you are making a call to an untrusted external contract,\u0026nbsp;\u003cem\u003eavoid state changes after the call\u003c/em\u003e. This pattern is also sometimes known as the\u0026nbsp;\u003ca href=\"http://solidity.readthedocs.io/en/develop/security-considerations.html?highlight=check%20effects#use-the-checks-effects-interactions-pattern\"\u003echecks-effects-interactions pattern\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-107\"\u003eSWC-107\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"dont-use-transfer-or-send\"\u003eDon’t use\u0026nbsp;\u003ccode\u003etransfer()\u003c/code\u003e\u0026nbsp;or\u0026nbsp;\u003ccode\u003esend()\u003c/code\u003e.\u003c/h4\u003e\n\n\n\n\u003cp\u003e\u003ccode\u003e.transfer()\u003c/code\u003e\u0026nbsp;and\u0026nbsp;\u003ccode\u003e.send()\u003c/code\u003e\u0026nbsp;forward exactly 2,300 gas to the recipient. The goal of this hardcoded gas stipend was to prevent\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/\"\u003ereentrancy vulnerabilities\u003c/a\u003e, but this only makes sense under the assumption that gas costs are constant. Recently\u0026nbsp;\u003ca href=\"https://eips.ethereum.org/EIPS/eip-1884\"\u003eEIP 1884\u003c/a\u003e\u0026nbsp;was included in the Istanbul hard fork. One of the changes included in EIP 1884 is an increase to the gas cost of the\u0026nbsp;\u003ccode\u003eSLOAD\u003c/code\u003e\u0026nbsp;operation, causing a contract’s fallback function to cost more than 2300 gas.\u003c/p\u003e\n\n\n\n\u003cp\u003eIt’s recommended to stop using\u0026nbsp;\u003ccode\u003e.transfer()\u003c/code\u003e\u0026nbsp;and\u0026nbsp;\u003ccode\u003e.send()\u003c/code\u003e\u0026nbsp;and instead use\u0026nbsp;\u003ccode\u003e.call()\u003c/code\u003e.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_2\" class=\"wp-block-code\"\u003e\u003ccode\u003e// bad\ncontract Vulnerable {\n    function withdraw(uint256 amount) external {\n        // This forwards 2300 gas, which may not be enough if the recipient\n        // is a contract and gas costs change.\n        msg.sender.transfer(amount);\n    }\n}\n\n// good\ncontract Fixed {\n    function withdraw(uint256 amount) external {\n        // This forwards all available gas. Be sure to check the return value!\n        (bool success, ) = msg.sender.call.value(amount)(\"\");\n        require(success, \"Transfer failed.\");\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eNote that\u0026nbsp;\u003ccode\u003e.call()\u003c/code\u003e\u0026nbsp;does nothing to mitigate reentrancy attacks, so other precautions must be taken. To prevent reentrancy attacks, it is recommended that you use the\u0026nbsp;\u003ca href=\"https://solidity.readthedocs.io/en/develop/security-considerations.html?highlight=check%20effects#use-the-checks-effects-interactions-pattern\"\u003echecks-effects-interactions pattern\u003c/a\u003e.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"handle-errors-in-external-calls\"\u003eHandle errors in external calls\u003c/h4\u003e\n\n\n\n\u003cp\u003eSolidity offers low-level call methods that work on raw addresses:\u0026nbsp;\u003ccode\u003eaddress.call()\u003c/code\u003e,\u0026nbsp;\u003ccode\u003eaddress.callcode()\u003c/code\u003e,\u0026nbsp;\u003ccode\u003eaddress.delegatecall()\u003c/code\u003e, and\u0026nbsp;\u003ccode\u003eaddress.send()\u003c/code\u003e. These low-level methods never throw an exception, but will return\u0026nbsp;\u003ccode\u003efalse\u003c/code\u003e\u0026nbsp;if the call encounters an exception. On the other hand,\u0026nbsp;\u003cem\u003econtract calls\u003c/em\u003e\u0026nbsp;(e.g.,\u0026nbsp;\u003ccode\u003eExternalContract.doSomething()\u003c/code\u003e) will automatically propagate a throw (for example,\u0026nbsp;\u003ccode\u003eExternalContract.doSomething()\u003c/code\u003e\u0026nbsp;will also\u0026nbsp;\u003ccode\u003ethrow\u003c/code\u003e\u0026nbsp;if\u0026nbsp;\u003ccode\u003edoSomething()\u003c/code\u003e\u0026nbsp;throws).\u003c/p\u003e\n\n\n\n\u003cp\u003eIf you choose to use the low-level call methods, make sure to handle the possibility that the call will fail, by checking the return value.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_3\" class=\"wp-block-code\"\u003e\u003ccode\u003e// bad\nsomeAddress.send(55);\nsomeAddress.call.value(55)(\"\"); // this is doubly dangerous, as it will forward all remaining gas and doesn't check for result\nsomeAddress.call.value(100)(bytes4(sha3(\"deposit()\"))); // if deposit throws an exception, the raw call() will only return false and transaction will NOT be reverted\n\n// good\n(bool success, ) = someAddress.call.value(55)(\"\");\nif(!success) {\n    // handle failure code\n}\n\nExternalContract(someAddress).deposit.value(100)();\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-104\"\u003eSWC-104\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"favor-pull-over-push-for-external-calls\"\u003eFavor\u0026nbsp;\u003cem\u003epull\u003c/em\u003e\u0026nbsp;over\u0026nbsp;\u003cem\u003epush\u003c/em\u003e\u0026nbsp;for external calls\u003c/h4\u003e\n\n\n\n\u003cp\u003eExternal calls can fail accidentally or deliberately. To minimize the damage caused by such failures, it is often better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically. (This also reduces the chance of\u0026nbsp;\u003ca href=\"https://consensys.github.io/smart-contract-best-practices/attacks/denial-of-service/\"\u003eproblems with the gas limit\u003c/a\u003e.) Avoid combining multiple ether transfers in a single transaction.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_4\" class=\"wp-block-code\"\u003e\u003ccode\u003e// bad\ncontract auction {\n    address highestBidder;\n    uint highestBid;\n\n    function bid() payable {\n        require(msg.value \u0026gt;= highestBid);\n\n        if (highestBidder != address(0)) {\n            (bool success, ) = highestBidder.call.value(highestBid)(\"\");\n            require(success); // if this call consistently fails, no one else can bid\n        }\n\n       highestBidder = msg.sender;\n       highestBid = msg.value;\n    }\n}\n\n// good\ncontract auction {\n    address highestBidder;\n    uint highestBid;\n    mapping(address =\u0026gt; uint) refunds;\n\n    function bid() payable external {\n        require(msg.value \u0026gt;= highestBid);\n\n        if (highestBidder != address(0)) {\n            refunds[highestBidder] += highestBid; // record the refund that this user can claim\n        }\n\n        highestBidder = msg.sender;\n        highestBid = msg.value;\n    }\n\n    function withdrawRefund() external {\n        uint refund = refunds[msg.sender];\n        refunds[msg.sender] = 0;\n        (bool success, ) = msg.sender.call.value(refund)(\"\");\n        require(success);\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eSee\u0026nbsp;\u003ca href=\"https://swcregistry.io/docs/SWC-128\"\u003eSWC-128\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003ch4 id=\"dont-delegatecall-to-untrusted-code\"\u003eDon’t delegatecall to untrusted code\u003c/h4\u003e\n\n\n\n\u003cp\u003eThe\u0026nbsp;\u003ccode\u003edelegatecall\u003c/code\u003e\u0026nbsp;function is used to call functions from other contracts as if they belong to the caller contract. Thus the callee may change the state of the calling address. This may be insecure. An example below shows how using\u0026nbsp;\u003ccode\u003edelegatecall\u003c/code\u003e\u0026nbsp;can lead to the destruction of the contract and loss of its balance.\u003c/p\u003e\n\n\n\n\u003cpre id=\"__code_5\" class=\"wp-block-code\"\u003e\u003ccode\u003econtract Destructor\n{\n    function doWork() external\n    {\n        selfdestruct(0);\n    }\n}\n\ncontract Worker\n{\n    function doWork(address _internalWorker) public\n    {\n        // unsafe\n        _internalWorker.delegatecall(bytes4(keccak256(\"doWork()\")));\n    }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\n\n\n\u003cp\u003eIf\u0026nbsp;\u003ccode\u003eWorker.doWork()\u003c/code\u003e\u0026nbsp;is called with the address of the deployed\u0026nbsp;\u003ccode\u003eDestructor\u003c/code\u003e\u0026nbsp;contract as an argument, the\u0026nbsp;\u003ccode\u003eWorker\u003c/code\u003e\u0026nbsp;contract will self-destruct. Delegate execution only to trusted contracts, and\u0026nbsp;never to a user supplied address.\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003cp class=\"has-background\" style=\"background-color:#f78da812\"\u003eFront-running is a pervasive issue in Ethereum DApps. DApp developers don’t necessarily have the mindset to design DApps with front-running in mind. This is an attempt to bring forward the subject and increase awareness of these type of attacks. While some DApp-level application logic could be built to mitigate these attacks, its ubiquity across different DApp categories suggests mitigations at the blockchain-level would perhaps be more effective. We highlight this as an important research area. We consider front-running to be a course of action where an entity benefits from prior access to privileged market information about upcoming transactions and trades. Front-running has been an issue in financial instrument markets since the 1970s. With the advent of the blockchain technology, front-running has resurfaced in new forms we explore here, instigated by blockchain’s decentralized and transparent nature. In this paper, we draw from a scattered body of knowledge and instances of front-running across the top 25 most active decentral applications (DApps) deployed on Ethereum blockchain. Additionally, we carry out a detailed analysis of Status.im initial coin offering (ICO) and show evidence of abnormal miner’s behavior indicative of front-running token purchases. Finally, we map the proposed solutions to front-running into useful categories\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/demining/Improving-Overall-Security\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eGitHub\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://t.me/cryptodeeptech\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eTelegram:\u0026nbsp;https://t.me/cryptodeeptech\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003ca href=\"https://youtu.be/HVh_cbsgSMg\" target=\"_blank\" rel=\"noreferrer noopener\"\u003e\u003cstrong\u003eVideo: https://youtu.be/HVh_cbsgSMg\u003c/strong\u003e\u003c/a\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://cryptodeeptech.ru/improving-overall-security\" target=\"_blank\" rel=\"noreferrer noopener\"\u003eSource: https://cryptodeeptech.ru/improving-overall-security\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\n\n\n\u003chr class=\"wp-block-separator has-alpha-channel-opacity\"\u003e\n\n\n\u003cdiv class=\"wp-block-image\"\u003e\n\u003cfigure class=\"aligncenter size-large\"\u003e\u003cimg decoding=\"async\" loading=\"lazy\" width=\"1024\" height=\"576\" src=\"./Improving the overall security of the ecosystem from attacks on smart contracts - CRYPTO DEEP TECH_files/035-1-1024x576.png\" alt=\"Improving the overall security of the ecosystem from attacks on smart contracts\" class=\"wp-image-1999\" srcset=\"https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-1-1024x576.png 1024w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-1-300x169.png 300w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-1-768x432.png 768w, https://cryptodeeptech.ru/wp-content/uploads/2023/03/035-1.png 1280w\" sizes=\"(max-width: 1024px) 100vw, 1024px\"\u003e\u003c/figure\u003e\u003c/div\u003e\n\n\n\u003cp\u003e\u003c/p\u003e\n\n\n\n\u003cp\u003e\u003c/p\u003e\n\t\u003c/div\u003e\u003c!-- .entry-content --\u003e\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdemining%2Fimproving-overall-security","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdemining%2Fimproving-overall-security","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdemining%2Fimproving-overall-security/lists"}