WrongSecrets lab: find hardcoded secrets and learn where secrets belong

OWASP WrongSecrets is an application that keeps secrets in the wrong places on purpose: in code, in front-end scripts, in configuration and in monitoring endpoints. Each challenge asks for one secret, and the application turns it green when the student finds the right one. This lab starts it in each student’s own private copy.

Everything the student looks into is inside their own lab copy, which has no route to the internet and none to any other student, so the only thing a student can reach is the application the lab started for them. The rule is said at the top of the lab: look into your own copy, never point a tool at a site you do not own.

What students learn

Where secrets leak from and how a developer or an attacker finds them: a password written into code, a secret shipped to the browser in a script, a key that a monitoring endpoint gives away. For each one they explain why the place is wrong and where a secret should be kept instead. It suits secure coding, DevOps and software supply chain units.

Run it in your browser

The application starts in a few seconds, needs no account and forgets its state when the lab stops, so a restart is a fresh game.

Only some challenges can be solved in a lab. The ones that ask for the project’s source from GitHub, a shell inside the application’s container, a cloud account, Vault, Kubernetes or an AI service need something a lab copy does not have. Challenges 0, 16 and 42 were checked, and others that are about the page, its scripts and its own endpoints are worth trying with the browser’s developer tools or curl in the lab’s terminal.

  1. Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
  2. Find the lab. The Sample labs card lists every sample. Find OWASP WrongSecrets.
  3. Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
  4. Open it. On the lab’s page, press the link named OWASP WrongSecrets, the lab’s Open button. Start at Challenge 0 in the Challenges menu, which explains the game. In the terminal, curl http://wrongsecrets:8080 reaches the application.

What to ask students to hand in

A screenshot of each challenge solved, with the lab’s own address visible, and for each a written explanation in their own words of where the secret was, how they found it, why that place is wrong and where a secret should be kept instead. The second half tells you whether it was understood or copied from a walkthrough.

The code on GitHub

The compose file runs WrongSecrets’ own public image, pinned to a release, as an unprivileged account. WrongSecrets is licensed under the AGPL-3.0 and is not distributed by us. The lab has no way out to the internet, so a challenge that needs one cannot be solved in it.

A basic lesson on this lab

WrongSecrets Basics is a small lesson worked in this lab, with each step explained and a Run button that types its command into the student’s own terminal. It starts with the rule that a student looks into their own copy and nothing else, checks the application is up, lists the endpoints the application exposes and looks at the script a front-end challenge is about, then sends them to the challenges.

A free personal account is given it on the Basics module, which is on Home, every college can copy it from the Library’s Basics folder, and a new college opens with it in a module called Lab Basics (Sample). It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

Set it as work

Say in the task which challenges to complete and what to hand in.

  1. Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-wrongsecrets with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it.
  2. Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start your own copy first.
  3. Hand it out. Assign it like any task, with a due date if you want one, and say in the task what to do and what to hand in.
  4. Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Questions people ask

Why can only some challenges be solved?
A lab copy has no way out to the internet and holds only the application. Challenges that need the project’s source on GitHub, a shell inside its container, a cloud account, Vault, Kubernetes or an AI service cannot be done in it. The page on GitHub says so too.
Is the progress kept?
No. The application keeps nothing, so stopping the lab and starting it again is a fresh game. A student who solved something takes a screenshot to hand in first.
Are the secrets real?
No. Every secret in the application is made up, for the game. The habit worth teaching is looking for the real ones in your own team’s code and never in somebody else’s.