Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. They are immutable and operate on a decentralized network such as the Ethereum blockchain. However, due to their complex nature, smart contracts are prone to vulnerabilities that can be exploited by attackers. Therefore, it is crucial to perform authentication testing of smart contracts to ensure their security and reliability.
Foundry, on the other hand, is a tool that can be used for this purpose. It is an open-source tool developed by ConsenSys that enables developers to test smart contracts for various vulnerabilities, including authentication issues, before deployment on the blockchain. This allows developers to identify and fix any security flaws in the code before it is executed on the blockchain, ensuring the integrity of the smart contract.
If you are more interested in reading about Foundry, you can refer to the article “Introducing Foundry and a Basic Test“. The blog is a comprehensive review of Foundry, a development toolchain. Initially, the article introduces a Web3 based VM, ZIION, which has all the required tools that a smart contract auditor will ever need. It then shows the installation of Foundry and its usage.
Article conducts a test on a basic Hello World program written in Solidity. The test showcases how one can write functional test cases and implement those in securing the Smart Contracts. The test results indicate that Foundry is fast, stable, and easy to use.
For the coarse of this article, I will be referring to the smart contract present at Walle.sol
Above contract is a wallet contract that can receive amount from anyone and only owner can withdraw the received amount. It also has a function, setOwner(), that can change owner and can only be called by existing owner.
I will be writing a testcase for setOwner() function to check if it can be called by addresses other than owner’s address.
Above contract is a wallet contract that can receive amount from anyone and only owner can withdraw the received amount. It also has a function, setOwner(), that can change owner and can only be called by existing owner.
I will be writing a testcase for setOwner() function to check if it can be called by addresses other than owner’s address.
wallet.t.sol
Walking through function testSetOwner(), wallet is deployed by authTest and authTest is the owner of the contract, wallet.setOwner() is called by authTest, so, it will be able transfer owner to a new address, i.e address(1).
Let’s run the test and check if it does what it is expected to do.
As you can see in the screenshot, addresses in wallet.SetOwner() and wallet.owner() are equal so, the test is passed.
Now, let’s write a failing test. Fail test’s naming convention is declared in Forge’s standard library, any test function that has fail in its name, is considered as a failing test case. And if the condition declared fails then the test passes.
wallet.t.sol(fail test case)
In the above failed test case, it is being checked if the setOwner() function can be called by address(1). Also, vm.prank() is introduced here, it pranks the failing function to consider the address passed in its argument as the owner of the contract.
As it is shown, test is passed, and it gave a message “caller is not owner” which was expected as the address(1) is not the contract owner.
Hence, the failing function failed and testcase eventually passed.
Conclusion
Now that you know how to write a passing and a failing test with the help of Foundry. One of the cheat-codes, vm.prank(), was also introduced that plays an important role on fail testcases. Eventually, the combination of aforementioned test cases will help you in your journey of becoming a Smart Contract Auditor.
Reference Links:
