InfoSec 3001 — Information Security from the Offensive Perspective

Step 151. Dreamhack Web Introduction — Your First Real Problems

Step 151. Dreamhack Web Introduction — Your First Real Problems

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

Prerequisites: through Step 150 complete. You can view HTML source and cookies with developer tools, and you know Base64 decoding and simple request manipulation.

  • What you need: an internet connection, a Dreamhack account (we create it today), developer tools, a personal wiki (write-up repository).
  • ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
  • Legal practice grounds: Dreamhack (dreamhack.io) is a legal learning platform that officially issues a "server you may attack" for every problem. Do not use today’s techniques anywhere outside the problem server addresses and your own local lab.

Every stage so far — Bandit, Natas, DVWA, Juice Shop — was "a fixed textbook." From today you solve "exam problems written by someone else." Dreamhack is a CTF platform (problem solving in a hacking-contest format) with Korean-language support, and for each problem it issues a temporary web server you can actually attack. Find the vulnerability, read the flag hidden somewhere on the server, and submit it — that’s the correct answer.

Nothing to be afraid of. The first problems are exactly the techniques you already know — viewing source, reading cookies, simple input manipulation. Today’s goals: learn the platform, review the first problem types in a local lab, then break 8 real problems.

1. Learning Objectives

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

  • Know the components of a Dreamhack wargame problem (title, description, URL, flag submission)
  • Read attack-target hints out of a problem’s title and description
  • Reproduce and solve the source-reading and cookie-decoding types in a local lab
  • Apply the recon → hypothesis → experiment → flag solving cycle to real problems
  • Write a write-up in a fixed format

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment Dreamhack wargame (browser) + Python 3 + Flask (local review lab)
Today’s commands Developer tools view-source, the Application tab’s cookies, base64.b64decode()
Concepts needed CTF and flags, the DH{...} format, problem deployment servers, the solving cycle
Today’s artifact 8 web problems solved + 2 write-ups

2-1. CTF and Flags — The Shape of a Correct Answer

A CTF problem’s correct answer is a special string called a flag. Dreamhack’s flags have the format DH{the_answer_goes_here}. Attack the problem server, find this string, and put it in the submission box on the problem page to receive points.

A flag is evidence that "I actually reached this server’s secret." Not a screenshot or an explanation — you must bring the string the server itself hid — so a solution leaves no room for excuses. This is why CTFs become a measure of skill.

2-2. How to Read a Problem Page

A Dreamhack web problem is usually composed like this (screen example — check the actual screen after signing up):

Title: cookie-monster        Difficulty: ★ 1    Solves: 1,234
Description: This site manages permissions with cookies. Only the admin can see the flag.
[Connect to server] → http://host3.dreamhack.games:12345/
[Submit flag] DH{____________________}

The title and description are the hints. See the word cookie and it’s a cookie-manipulation problem; see source and it’s a source-reading problem. Keep the rule "from difficulty 1 upward" — picking a hard problem first breaks your morale before you learn.

2-3. The Solving Cycle — Four Beats for the Real Field

Step 96’s cycle has evolved for web problems.

① Recon — tour every page of the problem server (view source, links, forms, cookies)
② Hypothesis — "what does this feature do inside?" write down vulnerability candidates
③ Experiment — change inputs, edit cookies, re-send requests with Burp
④ Flag — find DH{...}, submit it, record the solution

Beginners finish ① in 10 seconds and repeat only ③. A difficulty-1 flag is mostly visible if you just do ① recon thoroughly. The one who "reads" first wins.

2-4. A Preview of the First Problem Types

Difficulty 1–2 web problems are mostly three types.

Type What the problem hides What you do
Source reading A flag in HTML comments / JS files Read the entire source with developer tools
Cookies A permission cookie like role=guest Decode the value, then swap it
Simple input manipulation An unvalidated input box Trial inputs like SQLi or command strings

All of it is already learned. Today we get these types into our hands once more in the local lab, then head to the real field.

3. Follow Along

3-1. Local Lab — Finding a Flag Hidden in the Source

To see what a Dreamhack problem looks like, we build the same structure on our own computer. firstprob_lab.py:

from flask import Flask, make_response

app = Flask(__name__)

@app.route("/")
def index():
    html = """<!doctype html>
<html><body>
<h1>Welcome!</h1>
<p>Log in to unlock more features.</p>
<!-- TODO: delete before deploy. Temp admin memo: flag{view_source_is_free} -->
</body></html>"""
    resp = make_response(html)
    resp.set_cookie("session_role", "Z3Vlc3Q=")  # base64("guest")
    return resp

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

After running it (python firstprob_lab.py), connect to http://127.0.0.1:5493/ in a browser. The screen shows only "Welcome!" and one line of guidance. Now into recon mode — open the developer tools (F12) and view the whole HTML in the Elements tab.

The source the server actually sent (measured 2026-09-09):

<!doctype html>
<html><body>
<h1>Welcome!</h1>
<p>Log in to unlock more features.</p>
<!-- TODO: delete before deploy. Temp admin memo: flag{view_source_is_free} -->
</body></html>

How to read it: the fifth line, absent from the browser screen, is in the source. <!-- ... --> is an HTML comment — not drawn on screen, but the server definitely sent it. In the field too, developer memos, temporary passwords, and hidden paths are regulars in comments.

3-2. Reading and Decoding the Cookie

The same server also carried a cookie in its response. Check it in the developer tools Application tab → Cookies, or view the response headers.

Response header (measured 2026-09-09):

Set-Cookie: session_role=Z3Vlc3Q=; Path=/

The value looks like Base64 (the trailing = is the tell). Decode it with Python.

import base64
base64.b64decode("Z3Vlc3Q=").decode()

Output (measured 2026-09-09):

guest

How to read it: a declaration "your permission is guest" sits inside my browser. The next question comes naturally — what if I change this value to YWRtaW4= ("admin" in Base64)? Cookies can be edited freely by the client, and if the server trusts them without verification, it’s privilege escalation. The very attack you already did in Natas (Steps 102–104).

Why: fix an order for reading cookie values. ① Looks like Base64 → decode. ② Has two dots → JWT (Step 150). ③ Neither → manipulate the value itself. These three branches cover most difficulty 1–2 cookie problems.

3-3. Signing Up for Dreamhack and Deploying Your First Problem

Now for the real thing (screen example — the platform’s screens are yours to check):

  1. Go to dreamhack.io and sign up (email verification)
  2. Top menu Wargame → select web in the category
  3. Sort by difficulty and click the easiest problem first
  4. The problem page’s Connect to server button → a temporary server address is issued

How to read it: the issued address (in the form http://hostN.dreamhack.games:port/) is your own one-time practice server. It expires after a set time; when it expires, just get a new one issued. This address is the only target where attack is permitted.

3-4. Applying the Solving Cycle to Your First Problem

Say you’ve picked a difficulty-1 problem. Apply the cycle consciously.

① Recon: open the main page → read the entire HTML source with F12 → check cookies in the Application tab
        → also try connecting to robots.txt (/robots.txt)
② Hypothesis: "the cookie's named role — a permission problem" / "there's a comment — a source problem"
③ Experiment: decode/change cookie values, trial values in input boxes, re-send requests with Burp
④ Flag: found DH{...} → submit on the problem page → record

When a problem won’t yield, going back to ① is the standard move. "Something was missed in recon" is the #1 cause of being stuck.

3-5. Writing Your First Write-up

Once you’ve solved a problem, write while the memory is hot. Make dreamhack-001.md in your personal wiki, in this format:

# Problem: (title) — Difficulty ★
- **Situation**: (one-line summary of the problem description)
- **What I saw in recon**: (what stood out among source, cookies, forms)
- **Hypothesis**: (what vulnerability I thought it was)
- **What I tried**: (what I actually did, failures included)
- **The winning payload**: (the decisive move)
- **What I learned**: (one sentence ready for next time)

Be sure to record failures under "What I tried." A failure list is an asset that erases "been there, tried that" on the next problem. Posting the flag string itself in public places is against CTF etiquette — keep it only in your personal wiki.

4. Missions & Exercises

Mission — The First 8 Problems and a Recording Habit

  1. In the local lab (firstprob_lab.py), find both the flag in the source and the cookie value
  2. Sign up for Dreamhack and solve 8 difficulty 1–2 problems in the web category
  3. For all 8 problems, leave the four beats — recon → hypothesis → experiment → flag — in your notes
  4. Of those, complete 2 problems as write-ups in the 3-5 format

Exercises

Exercise 1. Explain why a flag plays the role of "evidence." Why is a screenshot insufficient?

Exercise 2. How can information exist that’s invisible on the browser screen yet present in the HTML source? Explain based on the 3-1 measurement.

Exercise 3. Write out the three-branch judgment order for when you meet a cookie value (Base64? JWT? raw manipulation?), with each branch’s identifying feature.

Exercise 4. When a problem won’t solve, which beat of the cycle should you return to, and why?

5. Model Answers & Completion Criteria

Mission Model Answer

The item-1 local lab answers (measured 2026-09-09): flag{view_source_is_free} in the source comment, and the cookie session_role=Z3Vlc3Q= → guest. The discovery procedure is exactly 3-1 and 3-2.

Items 2–3 proceed on the platform. Your 8-problem notes pass if they look like this (screen example):

Problem A — recon: index page + cookie role=guest found / hypothesis: cookie manipulation
        / experiment: changed role to admin and refreshed / flag: submitted

If the "hypothesis" box of an item-4 write-up is empty, you skipped beat ② — go back and fill it in.

How to verify: ① is the solve count on your Dreamhack profile 8 or more? ② do the 2 write-ups state "the winning payload" concretely? ③ does every problem note carry all four beats?

Exercise Answers

Answer 1. A flag is the hidden string inside the server itself, so presenting it is the sole evidence that you actually reached the server’s secret spot. A screenshot can be faked or copied, but the random string inside DH{...} cannot be known without breaching that server.

Answer 2. The server sends the entire HTML document, and the browser renders only the parts meant for the screen. An <!-- --> comment is merely a "don’t draw this" marker — it is still transmitted. In the 3-1 measurement, the admin memo absent from the screen was intact in the source — the screen is a subset of the server’s response.

Answer 3. ① Ends in = or is an alphanumeric + +// combination → Base64 candidate: decode it and read the meaning. ② Two dots (.) → JWT: Step 150’s dissection procedure. ③ Neither → plaintext like role=guest: change the value itself and experiment. The identifying features are, respectively, "padding characters," "two dots," and "readable plaintext."

Answer 4. Return to recon (①). Getting stuck on difficulty 1–2 problems is mostly not "can’t solve" but "haven’t seen" — an unread JS file, an unchecked cookie, an untried path (robots.txt, etc.). More experimenting helps only when the hypothesis is right.

Completion Criteria Checklist

  • [ ] I know the components of a Dreamhack problem page (title, description, server address, submission box)
  • [ ] I know the DH{...} flag format and can submit one
  • [ ] I found information hidden in an HTML comment with developer tools
  • [ ] I decoded a cookie value with Base64 and ran a change experiment
  • [ ] I applied the recon → hypothesis → experiment → flag cycle in order
  • [ ] I understand that problem server addresses are one-time and expire
  • [ ] Mission: 8 web problems solved + 2 write-ups complete

6. Common Pitfalls & Fixes

Wall 1. The problem server won’t connect

Symptom (output example):

This site can't be reached / ERR_CONNECTION_TIMED_OUT

Cause: the deployed temporary server expired, or your company/school network blocks unusual ports.
Fix: get the server re-deployed from the problem page. If it still fails, try from a different network (mobile hotspot, etc.). Also check the leading http:// and the port number are exact.

Wall 2. I viewed the source but there are no comments

Cause: you may have looked only at the Elements tab and not the original response in Network. If a framework rewrites the DOM later, it differs from the initial source.
Fix: use Ctrl+U (view source) to see it "exactly as the server sent it." Open JS files one by one in the Sources tab and search with Ctrl+F for flag, DH{, TODO.

Wall 3. I changed the cookie but nothing changes

Cause: you didn’t refresh the page after editing the cookie, or the server verifies the cookie (a signed session), or the value format is wrong.
Fix: ① always refresh after changing a value in the Application tab. ② if you changed a Base64 value, check you re-encoded it. ③ if it still fails, "the server verifies" is the hypothesis — move on to Step 150’s signature concept.

Wall 4. I found the flag but submitting says it’s wrong

Cause: whitespace got copied along, DH{ or } is missing, or you transcribed look-alike characters wrong (0 and O, 1 and l).
Fix: the rule is copying the flag whole, starting at DH{ and ending at }. Paste it into a notepad, check the whitespace, then submit.

Wall 5. Thirty minutes and no clue at all

Cause: you picked too high a difficulty, or it may be a problem using a technique you haven’t learned yet.
Fix: ① look at the problem page’s hints and solve count — few solves means a hard problem. ② drop down to difficulty 1. ③ if still stuck, record it and move to the next problem. Failure is also write-up material.

7. Summary

Today’s Concepts

Concept One-line explanation
CTF A hacking problem-solving contest/practice format where you find and submit flags
Flag The answer string hidden on the server — DH{...} on Dreamhack
Deployment server A one-time practice server issued per problem (expires)
Solving cycle Recon → hypothesis → experiment → flag
Write-up A solution record of situation, attempts, payload, lessons
Screen ⊂ source The screen is part of the server’s response — view-source is recon’s basics

Today’s Commands & Tools

Command/tool What it does
Ctrl+U / Elements tab Read the original HTML the server sent
Application tab → Cookies Check and edit cookies
base64.b64decode("...") Decode a cookie value
Connecting to /robots.txt Find hidden-path hints
Problem page Connect to server Issue a one-time practice server

An Instinct More Important Than Commands

When you meet a real problem, stop your hands and read first. A difficulty-1 flag is not "something that comes out by attacking" but "something visible if you read thoroughly." And records are letters to your future self — a problem you solve today, you a month later may fail to solve again. One write-up prevents that relapse. Lastly: being stuck is not failure but information for choosing the next problem.

Once every box is checked, Step 151 is complete.

← 이전 스텝
다음 스텝 →