Smart contracts cracking competition
impapichuksxx opened this issue · 2 comments
Smart contract cracking competition. -by merit smart contracts has been the most advanced by technology In the web 3 crypto space, making it almost impossible for vulnerabilities, using a secured maths library may still lack precision when integer arithmetic. When data is stored in resizable arrays and then accessed by looping through these arrays the transactions can quickly exhaust and roll back, these happens when the numbers of items increase with productions not testing. The test dataset is usually smarter than the product dataset which makes this vulnerability very dangerous. -lack of access control creates a room for vulnerability where only certain type of user should be allowed to call a certain functions but it’s not done. -mostly simple logical bugs arithmetic errors,these errors may be as a result of simple typo, a misunderstanding of specification or a larger programming mistake they tend to have complications on the smart contracts. -manipulation in solidity contracts which could result in our type inference heuristic failing furthermore. Most of the contracts using manipulator to manipulate variables as a bit arrays. - smart contracts can be written in any language that can compile to web assembly C++ is the most popular, however the combination of C++ and WASM can cause a lot of security issues in the network including the recent discovered EOSNodeREC vulnerability. EOS allows developers to update code on the blockchain however so many issues can be fixed as soon as they are discovered also by implementing an efficient. -Denial of service is very dangerous to smart contracts this kind of attack can break the normal operation of smart contracts and even lead to the collapse of smart contracts. Denial of service will consume the service capacity of smart contracts, finally the attack smart contracts can not provide service to other users. The attack can set too large value of variables to each functions to end the loop in this case the smart contracts cannot accept other users request and serve them. By these junction I come to an end with some few vulnerability of smart contracts I hope I made an impact. Impapichuksxx
Emmanuelchuks104@gmail.com
Hope for a reply
All smart contracts security vulnerabilities eventually lead to exploits, which negatively affects the reputation of the protocol, its owners, and the project team. Moreover, it lowers the overall level of trust to the industry, creating more concern and doubt.
As a developer, sometimes we focus too much on the functionality and performance offered by our applications and we tend to forget about security. Security is always important but it is paramount when it comes to smart contracts deployed on public blockchains (like Ethereum).
Saving unencrypted confidential data on the blockchain is very risky because the blockchain is accessible to anyone meaning that absolutely nothing about it is confidential, if by mistake, you save passwords (or similar information) on it, you are in big trouble. So I say NEVER store confidential information on a blockchain unless you encrypt it or hash it.
The state of a smart contract is determined by the values of its variables, which are changed by calling its functions. Calling a smart contract function is the same transaction as a transaction of ETH or ERC-20 token transfer. These transactions are finalized by the network only after the next block creation is complete.
Thus, when the user sends a transaction to call a contract function, they cannot be sure that the transaction will be executed in the same state of the contract in which it was at the time of sending. This can happen because other transactions in the same block have changed the state of the contract.
Moreover, miners have some freedom in ordering transactions when forming a block, as well as in choosing to include a particular transaction in a block. In some cases, the impossibility of determining the state of the contract, in which the transaction will be executed, can cause another smart contract weakness.
It also becomes especially dangerous to interact with contracts written in such a way that their behavior can be changed over time.
Also, If you are used to other programming languages you might be tempted to use arrays more than you actually should.
Keep in mind that executing functions in Ethereum costs gas (money), and transactions have a gas limit by definition (the gas limit of a single block). If for some reason your smart contract uses a very long array, and at some point, you need to iterate through it, you might reach the gas limit making the function unexecutable….
So I say always try to use mappings when you expect a long list of values.
Writing a completely secure smart contract is a complex and painstaking task. Yet, however perfect the contract may seem, it still requires a thorough security audit before being published on the network.
The reason for that is many smart contract vulnerabilities that can be easily overseen even by experienced developers. Yet, even minor bugs may lead to massive protocol exploits and money loss. That is why we highly recommend you conduct at least two smart contract audits to boost your protocol security and prevent potential hacks.