Security Onboarding

Introduction

Clarification: This is a work in progress. In the future, more challenges will be added and things will be tweaked according to onboarders' feedback.

Flawed logic will get exploited in smart contracts. This is particularly true when funds are at play. Due to this, it is crucial for developers to understand the intricacies of the field, as well as to learn to not write code for the simple act of finishing a task and be done with it. Hasty programming as well as a lack of grasp of the potential attacks employed to exploit smart contract is a recipe for disaster.

Don't believe me?

The ecosystem is as exciting as it is hostile. Most code is open source, millions upon millions of dollars flow across smart contracts every day, security practices are not widespread and even if they are, human error still exists. In a field with these conditions, malicious actors are and will be aplenty.

Audits firms and competitive audits platforms have been created to mitigate this. However, they are expensive and far from flawless. Firms in particular may have all their slots reserved for months on end and the set of eyes reviewing your code—although it should be technically skilled—can be small. Competitive audit platforms have the benefit that more auditors inspect your code, but you can't always be certain of their expertise.

Moreover, entrusting your protocol to an external audit and relying all responsibility to them is irresponsible and lazy. Audits act as an extra layer of defense, but if the code provided to them is severely flawed, bugs can slip past.

In short, the security of a protocol starts with the core developers, is reviewed by auditors, revisited by the core developers, and put to the test by malicious actors after deployment.

But it always starts and ends with the core developers.

In this section of the onboarding, our goal is to familiarize you with the most common attacks, as well as to attempt to sear onto your brain the security mindset brand. We don't expect you to be an expert—this is a different profession altogether—but we expect you to be conscious about the code that you're writing.

To accomplish this, we will hurl a battery of challenges your way. You will have to find the bugs, complete test files showing how the bugs can be exploited, and write a description of the bug and exploit as well as an explanation as to how to mitigate it.

Taking the time to write these things down will ensure you understand what's happening and not just spewing things out of memory without true grasp of the situation or problem.

Suggested Preliminary Reading

• Landmines: Write up about smart contract developments, security, how to improve, and not-so-common practices.

Difficulty

Challenges

Challenges are divided into three categories based on their difficulty:

• EASY:
  • They involve awareness of certain EVM-behavior and concepts to be solved. These will be short and challenge your knowledge of certain tricks/features of solidity to ensure you are aware of them.
• MEDIUM:
  • They attempt to imitate bugs that can take place in real smart contracts. These are the meat of this part of the onboarding. These should be complex enough to make you stop and think about the vulnerabilities of the contract and how to exploit them.
• HARD:
  • These are here in case you have blazed through the easy and medium challenges. These should be complicated for even a seasoned dev to solve. They can be heavily technical, involving deep knowledge of one or many topics like the EVM, DeFi, etc. However, like mediums, they should stick to being close or imitations of real vulnerabilities. Otherwise, they become puzzles or brainteasers, which can be fun, but don't fully help with the security mindset.

Important Note:

The setups of the tests files you will have to complete for these challenges define the state the contract is currently in, so don't ignore the setup, it's valuable information.

Reports

For each challenge you will have to complete a report. Writing down reports is a crucial tool when it comes to learning. They help you improve your communication in terms of being clear and concise instead of overly verbose and confusing; they force you to think about the vulnerability or bug in a different light and in doing so, they reveal how well you understand it and push the concept deeper into your long-term memory.

Being great at communicating is an underrated skill in general. When working in teams it can save you time when explaining a concept or when doing pair-debugging. Not only this, if you ever find yourself in a war room having to explain a bug that you found to a handful of confused and stressed devs, the efficiency of your words will play a major role in the time it takes to transmit the information you have and them grasping it enough to come up with a plan of action. And in those situations, time is a ticking bomb.

Good reports explain the correct bug in a clear and concise manner. They provide relevant code snippets to minimize the amount of jumps between tabs the reader has to make as well as step by step explanation of how the attack would work in a simple scenario along with an actual test as proof of concept. All in all, these kind of reports should make the reader understand the bug immediately by not glossing over details and removing any ambiguity.

Note: Clear and concise doesn't mean reports should be short. It means they should be as long as the explanation of the vulnerability requires it.

Structure

• solidity/challenges/<difficulty>/<challenge_directory>: contains a description of the challenge as well as the contract of the challenge.
  • The challenge description includes what condition should be reached for the challenge to be considered solved as well as how many points the challenge grants.
• solidity/test/<challenge_name>: contains the test file where you will test your solution. It will come with predefined logic written in it so that you can focus on solving the challenge.
• reports/<difficulty>/<challenge_name>: contains a README file for each challenge with predefined titles. You will need to complete this once your test--which acts as proof of concepts--has passed. Each report will contain different sections for you to complete for the challenge to be considered solved.
• Inside of all the directories previously mentioned, you will find a example file which serves as an example of how to solve a challenge.

Test your Solutions

To test the solutions for a specific challenge:

forge test --match-contract <NAME_OF_TEST_CONTRACT> -vvvvv
// Example: forge test --match-contract Challenge_BribeLeaderboardAdmin -vvvvv

To test your solutions for all challenges:

yarn test:solutions

How to Submit your Solutions

1. Clone this repository
   1. Remember to do yarn install && forge install
2. Create a private repository of yours
3. Push solutions to your repository as pull requests
   1. Ideally, work on a different branch for each challenge named feat/challenge-name.
4. In your #onboarding channel in the discord ping the security reviewers to review your solutions
   1. Because these are isolated challenges, waiting for reviews should not delay you. Continue with the next challenge, don't wait for reviews.

Please don't ask for reviews of incomplete solutions. If you're hard stuck it may make more sense to continue with another challenge or investigate. If you are not that stuck but still can't find a way to solve the challenge, you can ask the reviewers to provide help or hints.

Adding a Challenge

The more challenges the better as long as the challenges contribute to the same goal of improving the challenger's mindset. Therefore, when adding a challenge, it's important that the vulnerability or bug featured has taken place in the past, or that it hasn't happened yet but has been caught in audits or it's likelihood of actually taking place is high.

If the challenge, or the idea behind the challenge, fits this criteria, contact any of the security reviewers so it can be approved or discussed.

If it is approved:

• Add the challenge following the repository's structure (report, readme, test file if needed) in a different branch and open a PR to dev.
• Write down the solution and share it with 0xGorilla or Billy so they can add it to the official solutions