OWASP Top 10 Secure Coding Challenges for Go

Blog
1

OWASP TOP 10 Secure Coding Challenges in Go
OWASP TOP 10 Secure Coding Challenges in Go1280×720 74.6 KB

Please find below a sample list of secure coding challenges for Go and their alignment with OWASP Top 10. The goal in each challenge is to fix the security vulnerability in the app. These are mix of free and Pro challenges.

:warning: To get started with SecDim’s challenges, first complete :point_right: Start Here.go.

A01:2021-Broken Access Control

  1. Bad Token.go: A token can be used for a one time operation: password reset, email verification, setting up multi factor authentication, etc. Therefore, secure generation and handling of the token is very important. In this challenge we will learn key security features that every token and token handling system must have.
  2. No Sutpo.go: This appsec challenge is inspired after Optus API incident. It has a number of security vulnerabilities in relation to API.
  3. Steam.go: This appsec challenge is inspired by the Steam client privilege escalation vulnerability. It showcases Time of Check, Time of Use (ToCToU) vulnerability. It is a hard to discover race condition vulnerability.

A02:2021-Cryptographic Failures

  1. Randomness.go: While there are libraries to generate random numbers, not all of them are suitable for security. This challenge will explore this weakness and ways to address it.
  2. Bad Token.go: A token can be used for a one time operation: password reset, email verification, setting up multi factor authentication, etc. Therefore, secure generation and handling of the token is very important. In this challenge we will learn key security features that every token and token handling system must have.

A03:2021-Injection

  1. Command Injection.go: when untrusted data is used as an argument to an external program, command injection can happen. In this appsec challenge, we explore how to exploit and fix command injection vulnerability.
  2. SQL Injection.go: This is a classic security challenge where an app uses a SQL database and does not use parametrised query or ORM.
  3. Log Injection.go: Although the Log4Shell RCE vulnerability took many by surprise, log injection has been a known vulnerability, and there are numerous other edge cases that can lead to the exploitation of log aggregators. In this challenge, we will explore how to construct a resilient logger.
  4. Ubor.go: This challenge is inspired by Uber RCE on rider.uber.com. We learn how to exploit and fix Server Side Template Injection (SSTI).
  5. Pollution.go: This challenge is inspired by the Android Master Key security flaw. We learn a popular security design flaw that is related to misinterpretation between different parsers.

A04:2021-Insecure Design

  1. Energy.go: This challenge is inspired by the Energy Australia security incident. It showcases a number of security vulnerabilities on an authentication functionality.
  2. Bad Password.go: A password or a memorized secret must possess a variety of security features. In addition to preventing users from selecting weak passwords, the program should implement crucial security checks on the chosen password and securely store it. This challenge explores essential security controls for a change password API.
  3. Bad Token.go: A token can be used for a one time operation: password reset, email verification, setting up multi factor authentication, etc. Therefore, secure generation and handling of the token is very important. In this challenge we will learn key security features that every token and token handling system must have.
  4. StackOverflow.go: This challenge is inspired by the StackOverflow outage security incident. It showcases insecure usage of regular expression engines to perform security validation. This can result into a different class of security vulnerability.

A05:2021-Security Misconfiguration

  1. Secret Leak.go: Secrets such as an API or encryption key are used for various security operations. Disclosure of the secret can severely undermine the security of the app. When a secret is mistakenly disclosed, it is not trivial to remove. This challenge examines key activities that must be performed to handle a leaked/disclosed secret.
  2. No Sutpo.go: This appsec challenge is inspired after the Optus API incident. It has a number of security vulnerabilities in relation to API.

A07:2021-Identification and Authentication Failures

  1. JWT.go: Official JWT libraries have done a good job in enforcing token security by default. However, there are still a number of weaknesses that can be introduced when signing and verifying JWT. This challenge examines a JWT vulnerability that could allow unauthorised access and a number of insecure configurations when generating a token.
  2. Bad Password.go: A password or a memorized secret must possess a variety of security features. In addition to preventing users from selecting weak passwords, the program should implement crucial security checks on the chosen password and securely store it. This challenge explores essential security controls for a change password API.
  3. Bad Token.go: A token can be used for a one time operation: password reset, email verification, setting up multi factor authentication, etc. Therefore, secure generation and handling of the token is very important. In this challenge we will learn key security features that every token and token handling system must have.
  4. No Sutpo.go: This appsec challenge is inspired after the Optus API incident. It has a number of security vulnerabilities in relation to API.

A08:2021-Software and Data Integrity Failures

  1. Command Injection.go: when untrusted data is used as an argument to an external program, command injection can happen. In this appsec challenge, we explore how to exploit and fix command injection vulnerability.

A09:2021-Security Logging and Monitoring Failures

  1. Log injection.go: Although the Log4Shell RCE vulnerability took many by surprise, log injection has been a known vulnerability, and there are numerous other edge cases that can lead to the exploitation of log aggregators. In this challenge, we will explore how to construct a resilient logger.

A10:2021-Server-Side Request Forgery

  1. SSRF.go. In this challenge we learn how to exploit and fix Server Side Request Forgery.
  2. Capital0.go: This challenge is inspired by the Capital One hack. It highlights a number of security checks that must be in place to protect against SSRF.

We host many other challenges that are not part of OWASP Top 10 but appears in today’s modern apps. You can find these challenges by

  1. Browsing through vulnerabilities related to Go apps: Browse Challenges
  2. Viewing the Go game

OWASP TOP 10 Secure Developer Badge - Go

Finally, you can win SecDim OWASP TOP 10 Secure Developer in Go Badge :trophy: to show your proficiency in building secure apps aligned with OWASP TOP 10 recommendations.