Web Frameworks: Python

This is the Python entry in the Web Frameworks module, and we are going to work it the way a security reviewer actually does: as a code review. Rather than poking at a black box and guessing, we are handed the application's source and asked to find the bugs by reading it, then prove each one on the running lab machine. This is white-box testing. When we can see how the code is written, the framework-specific mistakes stop being mysteries and become patterns we can grep for.

The application is built on two of Python's most common web frameworks. Django is batteries-included: it ships an ORM, an admin site, a templating engine, server-side sessions, and a middleware stack, all wired together out of the box. Flask is a micro-framework: it gives us routing and a request object and leaves the rest to us and to add-on libraries. The two have very different defaults, and a framework's defaults are exactly where its bugs tend to live. A setting that is convenient in development, a session model that trusts the client, a template call that compiles a string: each of these is a habit that turns into a vulnerability when it reaches production.

We read the redacted source to locate each framework-specific sink, then exploit the lab machine directly to recover the real flag. Secret values are blanked to <REDACTED> in the served source, so the source teaches us WHERE a bug lives, never the secret itself; we recover the real values by attacking the lab machine, which is reachable directly so we can point tooling such as curl and flask-unsign straight at it.

Learning Objectives

• Read Django and Flask source to locate framework-specific sinks
• Recover a Django SECRET_KEY from a DEBUG=True 500 error page
• Spot and exploit an ORM SQL injection that survives Django's parameterisation
• Decode and forge a Flask signed session cookie
• Detect and exploit Jinja2 server-side template injection to reach command execution
• Chain a reused secret across services to reach the highest privilege tier

Prerequisites

• Working knowledge of HTTP and the request/response cycle
• Familiarity with the OWASP Top 10
• Comfort reading Python (no writing required) and using curl from a terminal

Suggested prerequisite rooms: Web Frameworks: Code Review for the read, map, trace, triage, and verify method, Web Frameworks: Java, OWASP Top 10 2025: Insecure Data Handling, SQL Injection, and Content Discovery.

Machine Access

To begin, click the Start Lab Machine button below and give it a couple of minutes to boot. Everything on the lab machine runs in the browser: the landing page at http://MACHINE_IP/ is a split-pane source viewer, with a file tree of the application's source on the left, the selected file's redacted source in the middle, and the live application on the right. We read the source on the left and middle to locate each framework-specific sink, then exploit the live application, which is reachable directly at http://MACHINE_IP/app/. The right-hand pane mirrors that same app so we can see it rendering next to its source as we read, but all exploitation happens through curl and flask-unsign against the app directly, since a browser session in the iframe won't reflect cookies forged from the command line. There is no SSH login for the lab machine. All the tooling we need is preinstalled on the AttackBox; if you are working from a personal host, install the session-forging tool with pip install flask-unsign.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting both your AttackBox (if you're not using your VPN) and Lab Machines, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Attacker machine

Status:Off

Lab machine

Status:Off

Start Lab Machine