OWASP Top 10 Secure Coding Challenges for JavaScript

Blog
1

OWASP TOP 10 Secure Coding Challenges
OWASP TOP 10 Secure Coding Challenges1280×720 75.4 KB

Please find below a sample list of secure coding challenges for JavaScript 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.js.

A01:2021-Broken Access Control

  1. Bad Token.js: 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.js: This appsec challenge is inspired after Optus API incident. It has an number of security vulnerabilities in relation to API.
  3. Steam.js: This appsec challenge is inspired by Steam client privilege escalation vulnerability. It showcase Time of Check, Time of Use (ToCToU) vulnerability. It is a hard to discover race condition vulnerability.

A02:2021-Cryptographic Failures

  1. Randomness.js: 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. UUID.js: Although RFC 4122 has explicitly stated not to assume UUIDs are random, in practice they are used as a random identifier. Some versions of UUIDs are more predictable than others. This challenge examines the predictability of a UUID and ways to address it (coming soon).
  3. Bad Token.js: 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.js: 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.js: This is a classic security challenge where an app uses a SQL database and does not use parametrised query or ORM.
  3. Log Injection.js: 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.js: 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.js: This challenge is inspired by 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.js: This challenge is inspired by Energy Australia security incident. It showcase a number of security vulnerabilities on an authentication functionality.
  2. Bad Password.js: 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.js: 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.js: This challenge is inspired by StackOverflow outage security incident. It showcase insecure usage of regular expression engines to perform security validation. This can result into different class of security vulnerability.

A05:2021-Security Misconfiguration

  1. Energy.js: This challenge is inspired by Energy Australia security incident. It showcase a number of security vulnerabilities on an authentication functionality.
  2. Secret Leak.js: 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 examine key activities that must be performed to handled a leaked/disclosed secret.
  3. No Sutpo.js: This appsec challenge is inspired after Optus API incident. It has an number of security vulnerabilities in relation to API.

A07:2021-Identification and Authentication Failures

  1. JWT.js: 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 configuration when generating a token.
  2. Bad Password.js: 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.js: 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.js: This appsec challenge is inspired after Optus API incident. It has an number of security vulnerabilities in relation to API.
  5. Energy.js: This challenge is inspired by Energy Australia security incident. It showcase a number of security vulnerabilities on an authentication functionality.

A08:2021-Software and Data Integrity Failures

  1. Merge.js: The challenge shows a variant of JavaScript’s Prototype Pollution. Specially crafted JSON input can tamper with existing prototype objects and modify their behaviour.
  2. Deserialization.js. Deserialising an untrusted data can result into arbitrary code execution. This vulnerability has become more prevalent with usage of Machine Learning and AI models. In this appsec challenge, we learn how to exploit and fix insecure deserialisation vulnerability.

A09:2021-Security Logging and Monitoring Failures

  1. Log injection.js: 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.js. In this challenge we learn how to exploit and fix Server Side Request Forgery.
  2. Capital0.js: This challenge is inspired by 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 JavaScript apps: Browse Challenges
  2. Viewing the JavaScript game or Frontend game

OWASP Top 10 Secure Developer in JavaScript

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