Step 175. Level 2 Comprehensive Assessment: The Attack/Defense Response Table — Completing Two-Sided Thinking
Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 5 hours (two days recommended)
Prerequisites: Steps 96~174 completed. This chapter is Level 2’s graduation exam — no new attack techniques.
- What you need: a notebook (or an empty document file), your lab records so far, and half a day of time.
- Caution: today is a "making" day. You complete your own attack/defense response table, then go back to the steps that feel blurry.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
You’ve learned dozens of attack techniques. But someone who knows only attacks is half — every attack has a corresponding defense, and every defense has a bypass. Today we compress all of Level 2 into a one-page table of "attack × defense × bypass." Once this table takes root in your head, two-sided thinking is complete — see an attack and the defense comes to mind; see a defense and the bypass comes to mind, automatically.
1. Learning Objectives
By the end of this chapter, you will be able to:
- Explain Level 2’s major attack techniques as pairs with their matching defenses
- State each defense’s bypass possibility in one line, internalizing "defense ≠ absolute safety"
- Build the habit framework of writing your own attack/defense response table and keeping it updated
- Self-grade the Level 2 skill list into three levels: "can explain / can do / blurry"
- Do efficient review by re-practicing only the blurry items
2. Background Knowledge — Today’s Tools and Concepts
Today’s Tools at a Glance
| Category | Details |
|---|---|
| Language/environment | notebook and pen + just Python (Flask) and curl for verification |
| Today’s commands | no new commands — only curl -sI (view response headers) for verification measurements |
| Concepts needed | response thinking (attack↔defense), defense in depth, bypass possibility, 3-level self-grading |
| Today’s artifact | one attack/defense response table + a self-grading sheet + a re-practice list |
2-1. Why a "Table"
Learned one by one, attack techniques become a skill list; paired with defenses, they become a structure. Knowing SQL injection is different from knowing "SQL injection ↔ prepared statements, bypass: encoding/filter evasion." The latter is knowledge that works immediately in interviews, on the job, and in CTFs.
The table has another power — it shows you the empty cells. The cell where you stall on "what was the defense for this attack?" is exactly your gap.
2-2. Defense in Depth — Defense Is Not One Layer
Defense in depth is the principle of stacking defenses in multiple layers. As you confirmed in Step 174, every link of the chain can carry a defense, and the front links are cheaper to cut. Don’t write just one thing in the table’s "defense" cell — build the habit of writing the front defense and the back defense together.
2-3. Bypass Possibility — Knowing Defense Isn’t Perfect
Every defense cell carries one trailing line: "bypass possibility." If there’s a filter, there’s an evasion payload; if there’s MFA, there’s fatigue attack (MFA fatigue) and session theft. This isn’t about dismissing defenses — only someone who knows a defense’s limits can place it in the right position.
2-4. The Three Levels of Self-Grading
We expand the principle from Step 40 to Level 2 scale. Mark each skill with one of three levels:
- Can explain: I can explain it to someone else without opening the book
- Can do: I can reproduce it alone, even if I have to look up the commands
- Blurry: I read it, but I couldn’t do it now
"Blurry" is not a failure — it’s a re-practice reservation.
3. Follow Along
3-1. The Table’s Skeleton — Eight Lines We Build Together First
The table below is the response-table skeleton for Level 2’s core attacks. Today’s task is not copying it but filling in the rest yourself in this format.
| Attack (steps) | Principle in one line | Defense | Bypass possibility |
|---|---|---|---|
| SQL injection (104, 135~137) | input changes query syntax | prepared statements, ORM | filter-based defenses can be bypassed via encoding/comments |
| XSS (138~139) | input executes as HTML/JS | output encoding, CSP headers | filter evasion, DOM-based XSS |
| CSRF (140) | the browser sends the request for you | CSRF tokens, SameSite cookies | token-missing endpoints, GET-based state changes |
| File upload (141~142) | uploaded file gets executed | extension whitelist, no execution in upload folder | double extensions, MIME-check-only setups |
| Command injection (143) | input attaches to a shell command | forbid shell calls, pass argument arrays | filter evasion (space substitutes like ${IFS}) |
| LFI/RFI (144) | reading/including files via path input | path normalization, allowlist | ....//, encoding evasion |
| Online brute force (122) | indiscriminate login attempts | rate limiting, account lockout, MFA | spraying (165), distributed IPs |
| ARP spoofing (156~157) | MAC impersonation on the same block | static ARP, Dynamic ARP Inspection (DAI) | the limits of the local-network trust structure itself |
How to read it: look at the relationship among the four cells. You know the attack only when you can state the "principle in one line"; you know the defense only when you can state the "bypass possibility." These eight lines are for getting the feel — in 3-2 below, you fill in the rest.
3-2. Filling the Remaining Cells — Your Table
Fill the following items in the same four-cell format. Don’t leave a stuck cell empty — write the step number beside it; that becomes your re-practice list.
- Password spraying & credential stuffing (165)
- Offline hash cracking (123~124)
- SUID & privilege escalation (106, 125~126)
- PATH injection (108)
- DNS spoofing (159)
- Session & cookie attacks (134)
- IDOR & access-control bypass (149)
- JWT attacks (150)
- Social engineering (167)
- OSINT collection (170~171)
Writing tip: don’t try to make a perfect table in one sitting. The goal is a table that accumulates a few lines a day — one defense-bypass pair per attack. This table doesn’t end today; it’s a document that keeps growing through Level 3.
3-3. Verification Measurement — Checking That the Defense Is Visible
The response table must not live only in a document. A defense must be verifiable. Let’s verify the "XSS → CSP headers" row of the 3-1 table by hand.
First, look at the headers of a server without defenses (the Step 174 lab if it’s still running, or any Flask server):
curl -sI http://127.0.0.1:8174/
HTTP/1.1 200 OK
Server: Werkzeug/3.1.8 Python/3.12.14
Date: Wed, 09 Sep 2026 08:04:04 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 240
Connection: close
(Measured 2026-09-09.)
Now make a server with defense headers added on the same content (step175_hardened.py) and compare:
Input (step175_hardened.py)
from flask import Flask
app = Flask(__name__)
@app.after_request
def harden(resp):
resp.headers["X-Content-Type-Options"] = "nosniff"
resp.headers["X-Frame-Options"] = "DENY"
resp.headers["Content-Security-Policy"] = "default-src 'self'"
resp.headers["Server"] = "web" # erase the server version exposure
return resp
@app.route("/")
def index():
return "<h1>Hardened Site</h1>"
if __name__ == "__main__":
app.run(host="127.0.0.1", port=8175)
python step175_hardened.py
curl -sI http://127.0.0.1:8175/
HTTP/1.1 200 OK
Server: Werkzeug/3.1.8 Python/3.12.14
Date: Wed, 09 Sep 2026 08:04:26 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 31
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
Server: web
Connection: close
(Measured 2026-09-09.)
How to read the output: the difference between the two screens is the response table made real. Three lines of defense headers were added — corresponding respectively to blocking MIME sniffing, blocking clickjacking, and mitigating XSS (CSP).
But look closely — the Server: header appears twice. Werkzeug wrote its version first, and our web got appended after. "I overwrote the header" and "the header disappeared" are different. Applying a defense isn’t the end — only when you confirm again with the attacker’s eyes (curl) does it become a defense. This single screen is a miniature of today’s chapter.
Predict: on real production servers, hiding the Server header is done in the web server configuration (nginx’s
server_tokens off, etc.). Trying to erase it in framework code often produces two lines like the above — the defense’s "layer" is information worth writing in the response table too.
3-4. Self-Grading the Level 2 Skill List
Open your notebook and grade Level 2’s skills by section into three levels (can explain / can do / blurry). The section list:
| Section | Steps | Core skills |
|---|---|---|
| Wargame basics | 96~105 | Bandit/Natas, XOR analysis, first SQLi, cataloging techniques |
| Linux advanced | 106~110 | setuid, logs, PATH injection, links |
| Intrusion basics | 111~121 | Kali, MS2, recon, scanners, Metasploit, first shell, manual exploitation |
| Passwords | 122~124 | hydra, John, hashcat |
| Privilege escalation | 125~130 | SUID, linPEAS, post-exploitation, time attack |
| Web attacks | 131~150 | Burp, SQLi, XSS, CSRF, upload, web shells, command injection, LFI, IDOR, JWT |
| Real-world web | 151~155 | Dreamhack, independent conquest |
| Network | 156~166 | ARP/DNS spoofing, sniffing, TLS, firewalls, tunneling, wireless |
| Humans & info | 167~171 | social engineering, malware structure, OSINT |
| Capstones | 172~174 | Scenarios 1 & 2, reports, chain attacks |
Write one of "can explain / can do / blurry" for each section. Grading the ten sections takes 30 minutes at most.
3-5. Re-Practicing Only the Blurry Ones — Real Review
Pick only the sections graded "blurry" and go back to those steps. The re-practice rules are the same as Step 40:
- Concept is blurry: read that step’s ‘Background Knowledge,’ close the book, and explain it again in your own words
- Hands are blurry: redo only the ‘Follow Along.’ This time, cover the output examples and predict first
- Both are blurry: redo that step from the beginning — not a shame but the fastest path
When re-practice ends, fill that cell of the response table again. A cell that was left blank getting filled is the evidence that review is complete.
3-6. Previewing Level 3 — Next Is the Professional Track
Level 3 (Step 176~) is CTF practice and field specialization. You taste five fields (Web, Pwn, Reversing, Crypto, Forensics) and then choose your main. If you made the weakness/strength analysis in Step 154, take it out — the first clue to which field pulls you is in there.
You don’t need to decide now. Today’s task is closing Level 2.
4. Missions & Exercises
Mission — Completing My Attack/Defense Response Table
Including 3-2’s ten items, complete a response table covering at least 18 attacks total learned in Level 2. Rules:
- Fill all four cells (attack/principle/defense/bypass possibility) — for cells you don’t know, write the step number and update after re-practice
- In the defense cell, try to distinguish the front defense (prevention) from the back defense (detection/response)
- At the bottom of the table, a one-line summary: "which column (attack or defense) am I weakest at in this table"
Exercises
Exercise 1. Answer the question "can’t you just build a perfect defense?" using the concepts of defense in depth and bypass possibility.
Exercise 2. In the 3-3 measurement, the Server: header appeared twice. What lesson about applying defenses does this show?
Exercise 3. Name two attacks that bypass rate limiting (login attempt restrictions), from what you learned in Level 2.
Exercise 4. When three or more sections are marked "blurry" in self-grading, what is the recommended review order? (Hint: the sections’ dependency relationships)
5. Model Answers & Completion Criteria
Mission Model Answer
Reference answers for the 3-2 items (your table’s wording may differ — whether the four cells are filled is the criterion):
| Attack | Principle in one line | Defense | Bypass possibility |
|---|---|---|---|
| Password spraying (165) | 1 common password × many accounts | org-wide rate limiting, MFA, blocking leaked passwords | slow spraying, distributed IPs |
| Hash cracking (123~124) | offline guessing of leaked hashes | strong hashes (bcrypt/argon2), salts, long-password policy | weak hashes (MD5/SHA1), passwords in wordlists |
| SUID privilege escalation (106, 125) | abusing SUID programs | SUID minimization, filesystem audit, nosuid mounts | legitimate commands on GTFOBins |
| PATH injection (108) | running a fake command early in PATH | absolute-path calls, PATH hygiene | habitual relative paths in cron/scripts |
| DNS spoofing (159) | false name-resolution answers | DNSSEC, enforced HTTPS (HSTS) | internal-network trust, downgrade attempts |
| Session & cookie attacks (134) | stealing/fixing session IDs | HttpOnly/Secure/SameSite, session rotation | theft via XSS, side channels |
| IDOR (149) | changing an object number to reach others’ resources | server-side access control, indirect references | endpoints with authentication but missing authorization |
| JWT attacks (150) | alg=none, weak secrets | pinned alg, strong keys, short expiry | key leakage, missing claim validation |
| Social engineering (167) | exploiting human trust & urgency | education & drills, verification procedures, reporting culture | new lures, targeting organizational boundaries |
| OSINT (170~171) | combining public information | minimizing information exposure, asset inventories | the public itself can’t be blocked — only exposure managed |
An example of the one-line summary: something honest, like "the defense column is weak — for four cells I remembered the attack but the matching defense wouldn’t come." That one line becomes your learning priority in Level 3.
How to verify: ① 18 or more, ② is the bypass-possibility cell filled everywhere (if empty, it means you’re overtrusting that defense), ③ do cells updated through re-practice carry a mark?
Exercise Answers
Answer 1. Because there is no perfect defense. Every defense has a bypass possibility (filters have evasion payloads, lockouts have spraying), and the moment comes when one defense gets pierced. So defenses are stacked in multiple layers (defense in depth) — if one layer breaks, the next remains, and each layer raises the attacker’s cost. "Many imperfect layers," not "one perfect layer," is the field’s answer.
Answer 2. That a defense must be judged not by the fact that it was applied but by verified results. We believed the header was "overwritten" in code, but checking with the attacker’s eyes (curl -sI) showed the original header written by the framework still exposed. Defense is completed by observation, not configuration — the same commandment as Step 40’s "don’t trust, verify."
Answer 3. ① Password spraying — to dodge per-account attempt limits, try one password once each against many accounts. ② Credential stuffing — replay real id/password pairs leaked from other sites, so no "guessing" happens at all. Both are Step 165’s topics, and the responses are org-wide limits, MFA, and blocking leaked passwords.
Answer 4. Go from the front of the dependency chain. Example: if "privilege escalation (125) is blurry" and "Scenario 2 (174) is blurry" come out together, 174 is a capstone that uses 125, so you must re-practice 125 first. Since this book’s structure is the chain entrance→foothold→settling→domination, filling from the chain’s front links is always faster.
Completion Criteria Checklist
- [ ] I completed a response table of 18+ attacks in the four-cell format (attack/principle/defense/bypass possibility)
- [ ] I wrote each defense’s bypass possibility in one line
- [ ] I confirmed "defense is verified by observation" with the defense-header measurement
- [ ] I self-graded Level 2’s ten sections into three levels
- [ ] I made a re-practice list (step numbers) for the "blurry" sections
- [ ] I actually re-practiced at least one blurry section and updated the table
- [ ] I wrote a one-line "my weak column" summary at the bottom of the table
6. Common Pitfalls & Fixes
Wall 1. Trying to complete the table in one sitting and burning out
Symptom: trying to fill all 18 in one sitting, your hands stop midway.
Cause: the table is not an exam but a living document.
Fix: today, do only the skeleton (3-1’s eight lines) and the self-grading; fill the rest over several days as you re-practice. A "table that keeps getting updated" is worth more than a "perfect table."
Wall 2. The defense cells won’t fill
Symptom: you remember the attack but the defense won’t come to mind.
Cause: a normal bias — this is an attack-perspective book, so defenses emerge only by flipping attacks.
Fix: look at the attack’s one-line principle and flip it: "which link of this principle do I cut?" If SQLi’s principle is "input changes query syntax," the cut is "separate input from syntax (prepared statements)." Defense is the attack’s mirror.
Wall 3. In 3-3, the Server header still shows the version
Symptom: even with the hardening code in, the line Server: Werkzeug/3.1.8 Python/3.12.14 remains.
Cause: that’s normal — Werkzeug writes its own header first, and @after_request adds another header on top. It becomes two lines (measured 2026-09-09).
Fix: rather than trying to fix it, this phenomenon itself is today’s learning. In production environments, the header is removed at the front web server (nginx, etc.). "At which layer you apply the defense" is also information for the response table.
Wall 4. The self-grading comes out all "can explain"
Symptom: the grading is lenient.
Cause: grade with the book open and everything feels known.
Fix: close the book and explain aloud for 60 seconds one core skill from each section. If you stall, that’s "blurry." Strictness is everything in this exam — a lenient grade steals your re-practice list.
Wall 5. Too many blurry sections
Symptom: the re-practice list exceeds five.
Cause: nobody remembers 80 steps at once. Forgetting is the default specification.
Fix: rename the list to "next-steps schedule." From the front links (Exercise 4’s principle), one section a day. Five re-practices and it’s all filled before Level 3 begins.
7. Summary
Today’s Concepts
| Concept | One-line explanation |
|---|---|
| Attack/defense response table | Four cells — attack, principle, defense, bypass possibility — Level 2’s compressed file |
| Two-sided thinking | A state where seeing an attack recalls the defense, and seeing a defense recalls the bypass |
| Defense in depth | many imperfect layers > one perfect layer |
| Bypass possibility | A tag attached to every defense cell — knowing the limits is what makes a professional |
| 3-level self-grading | can explain / can do / blurry — blurry is a re-practice reservation |
| Verifying defense | configured ≠ blocked — look again with the attacker’s eyes (curl) |
Today’s Commands
| Command | What it does |
|---|---|
curl -sI URL |
Viewing only response headers — the verification tool for defenses (security headers) |
An Instinct More Important Than Commands
In Level 2 you traveled from a wargame’s first flag, to your first shell, every type of web attack, network spoofing, and yesterday’s chain attack. That long list became a single page of table today. Don’t take it lightly because the table looks short — being compressed means it can be unfolded again anytime, and that is skill.
And remember this table’s real use. The "remediation" section of a pentest report, the interview’s "how would you stop this attack," the "priorities" of building a defense — all are cells of this table. The moment what you learned as an attacker translates into the defender’s language, you know both grammars of this field.
Congratulations on graduating Level 2. You are not a beginner anymore — you are a prepared learner.
Once every box is checked, Step 175 is complete. Click the checkbox in the sidebar to save your progress.