Now the user is properly logged in; the question is what they're allowed to reach. A broken access control, often called IDOR, is when the app checks that you're logged in but not that the thing you're asking for is yours. It's currently the number one risk on the OWASP Top 10.
\nA logged in user opens /invoice?id=105 and sees their own invoice. They change it to /invoice?id=106 and see a stranger's, because the server looked up the invoice by ID without checking who owns it.
Every request for a specific record must verify the current user is allowed to see that record, server side. Hiding the admin link in the menu does nothing, because the URL can be typed directly.
\nTwo steps. Change an ?id= value to read another user's invoice, then request an /admin page that has no role check at all. The flag sits on the admin page.
Now the user is properly logged in; the question is what they're allowed to reach. A broken access control, often called IDOR, is when the app checks that you're logged in but not that the thing you're asking for is yours. It's currently the number one risk on the OWASP Top 10.
\nEvery request for a specific record must verify the current user is allowed to see that record, server side. Hiding the admin link in the menu does nothing, because the URL can be typed directly.
","quiz":[{"q":"A user changes /invoice?id=105 to another id and sees a stranger's invoice. The missing control is:","options":["Input validation on the id","A check that the invoice belongs to the current user","HTTPS on the endpoint","Rate limiting"]},{"q":"Why doesn't hiding the admin link in the UI protect /admin?","options":["The user can request the URL directly regardless of the UI","The link is cached by the browser","Search engines index the link","The CSS can be disabled"]}],"lab":{"type":"container","image":"cyberforge/access-control","objective":"Read another user's invoice by id, then reach the unprotected admin page","needs_flag":true,"needs_code":false}},"authentication":{"id":"authentication","title":"Authentication Boundaries","unit":3,"branch":"web","difficulty":2,"prereqs":["cookies-sop","untrusted-input"],"lab_type":"container","has_quiz":true,"body_html":"Authentication is proving who you are, usually with a password. Its weak points aren't exotic: leaky error messages that reveal valid usernames, no limit on guesses, and weak or reused passwords. Together they let an attacker find a real account and guess their way in.
\nA login that says "user not found" for one input and "wrong password" for another is quietly telling an attacker which usernames exist. Once they have a valid username and there's no rate limit, they can try thousands of passwords until one works.
\nUse one generic failure message for both cases, rate limit and lock out after repeated failures, and store passwords with a slow salted hash like bcrypt so a stolen database isn't instantly crackable.
\nFirst use the differing error messages to confirm a valid username, then brute force its password against a small supplied wordlist. Logging in reveals the flag. Rate limiting is deliberately off so the attack is visible; the debrief points out that fixing it is the defense.
","short_html":"Authentication is proving who you are, usually with a password. Its weak points aren't exotic: leaky error messages that reveal valid usernames, no limit on guesses, and weak or reused passwords. Together they let an attacker find a real account and guess their way in.
\nUse one generic failure message for both cases, rate limit and lock out after repeated failures, and store passwords with a slow salted hash like bcrypt so a stolen database isn't instantly crackable.
","quiz":[{"q":"Why is a login that says 'user not found' vs 'wrong password' a problem?","options":["It lets an attacker confirm which usernames exist","It leaks the password hash","It disables rate limiting","It exposes the session cookie"]},{"q":"Which most directly stops online password brute forcing?","options":["Longer password hashes","HTTPS on the login page","Rate limiting and lockout after failed attempts","A CAPTCHA on the signup page"]}],"lab":{"type":"container","image":"cyberforge/authentication","objective":"Enumerate a valid username, then brute force its password","needs_flag":true,"needs_code":false}},"capstone-chain":{"id":"capstone-chain","title":"Chained Attack","unit":6,"branch":"web","difficulty":5,"prereqs":["access-control","xss","csrf"],"lab_type":"container","has_quiz":false,"body_html":"Real attacks are rarely one trick; they're a chain where each step opens the next. The capstone drops you into one vulnerable app with a single goal and no hand holding, and only a chain of earlier skills gets you there. It proves you can connect lessons, not just pass them one at a time.
\nA possible path through the box: use IDOR to enumerate users and find an admin account, plant a stored XSS payload that steals the admin's session when their bot views it, then use that session to reach an admin only page holding the final flag. You may find other valid chains.
\nWalk back through the chain and name the one fix at each step that would have broken it: an ownership check, output encoding, a role check on the admin page. Defense in depth means an attacker has to beat all of them, not just one.
\nOne container, one final flag, unlocked only after Units 1-4 are complete. No step by step objective is given on purpose; a hint system can reveal the next stage if you're stuck.
","short_html":"Real attacks are rarely one trick; they're a chain where each step opens the next. The capstone drops you into one vulnerable app with a single goal and no hand holding, and only a chain of earlier skills gets you there. It proves you can connect lessons, not just pass them one at a time.
\nWalk back through the chain and name the one fix at each step that would have broken it: an ownership check, output encoding, a role check on the admin page. Defense in depth means an attacker has to beat all of them, not just one.
","quiz":[],"lab":{"type":"container","image":"cyberforge/capstone-chain","objective":"Chain IDOR, XSS, and session takeover to reach the admin flag","hints":true,"needs_flag":true,"needs_code":false}},"command-injection":{"id":"command-injection","title":"Command Injection","unit":2,"branch":"web","difficulty":3,"prereqs":["sqli"],"lab_type":"container","has_quiz":true,"body_html":"Same root cause as SQLi, different target: instead of a database, the input reaches the operating system shell. If an app builds a shell command out of user input, an attacker can tack on commands of their own.
\nA network tool runs os.system("ping " + host). Sending a host value with a ; followed by another command makes the shell run ping, then run the attacker's command, because ; chains commands.
Don't call the shell with a built string. Pass arguments as a list straight to the program (subprocess.run(["ping", host])), which removes the shell parsing that makes injection possible. Blocklisting characters leaks.
The container has a "ping a host" page. Inject a second command to read flag.txt from the server's filesystem. Because real shell access is possible, this lab needs the hardened container (no network out, unprivileged, read only except a scratch dir).
Same root cause as SQLi, different target: instead of a database, the input reaches the operating system shell. If an app builds a shell command out of user input, an attacker can tack on commands of their own.
\nDon't call the shell with a built string. Pass arguments as a list straight to the program (subprocess.run(["ping", host])), which removes the shell parsing that makes injection possible. Blocklisting characters leaks.
HTTP has no memory, so sites use cookies to remember you between requests. After login the server gives you a session cookie, and your browser sends it back on every request so the server knows who you are. The Same Origin Policy is the rule that keeps one site's pages from reading another site's data in your browser. These two ideas underpin XSS, CSRF, and session attacks, so they come before all of them.
\nScript on evil.com can send a request to bank.com, and your bank cookie goes along automatically, but the Same Origin Policy stops evil.com from reading the response. That one way gap is exactly why CSRF works and why stealing data cross origin usually doesn't.
Protect session cookies with flags: HttpOnly hides them from JavaScript, Secure keeps them off plain HTTP, and SameSite limits when they're sent to other sites. Each one blocks a different attack you'll meet later.
The app stores the user's role in a cookie like role=user. Change it to role=admin, resend the request, and unlock an admin page holding the flag. It shows why trusting a client side value is dangerous.
HTTP has no memory, so sites use cookies to remember you between requests. After login the server gives you a session cookie, and your browser sends it back on every request so the server knows who you are. The Same Origin Policy is the rule that keeps one site's pages from reading another site's data in your browser. These two ideas underpin XSS, CSRF, and session attacks, so they come before all of them.
\nProtect session cookies with flags: HttpOnly hides them from JavaScript, Secure keeps them off plain HTTP, and SameSite limits when they're sent to other sites. Each one blocks a different attack you'll meet later.
CSRF abuses the fact that the browser automatically attaches your cookies to any request to a site, even one triggered by a different site. So a malicious page can make your browser send a real, authenticated request to a site you're logged into, without the attacker ever seeing the response.
\nYou're logged into your bank. You visit a malicious page that submits automatically a hidden form to bank.com/transfer. Your bank cookie rides along, the bank sees a valid logged in request, and the transfer goes through. The Same Origin Policy stops the attacker reading the reply, but the action already happened.
Defend with a CSRF token: a secret, per session random value the real form includes and the attacker can't know. SameSite cookies are a strong complementary defense, since they stop the cookie being sent on cross site requests.
Two parts. First (container), build an attacker page that makes a logged in bot change its account email, proving the forgery works. Second (code), add a CSRF token to the form and its server check; the test confirms the attack page now fails while the legitimate form still works.
","short_html":"CSRF abuses the fact that the browser automatically attaches your cookies to any request to a site, even one triggered by a different site. So a malicious page can make your browser send a real, authenticated request to a site you're logged into, without the attacker ever seeing the response.
\nDefend with a CSRF token: a secret, per session random value the real form includes and the attacker can't know. SameSite cookies are a strong complementary defense, since they stop the cookie being sent on cross site requests.
HTTP is the format of every request and reply. A request has a method (GET, POST, and others), a path, headers (extra info like cookies and content type), and sometimes a body. A response has a status code (200 OK, 302 redirect, 404 not found), its own headers, and a body. Every attack later in this module is just a carefully written HTTP request, so you need to read and write them comfortably.
After a successful login the server might reply 302 Found with Location: /dashboard and Set-Cookie: session=abc. The browser stores the cookie and automatically sends GET /dashboard with it attached. Nothing here is magic; it is all visible, and all editable, in an intercepting proxy.
Any part of a request can be changed by the sender: method, path, headers, cookies, hidden fields, body. Treat all of it as attacker controlled when you design a server.
\nRead a flag out of a custom response header, then send a request with a method the web form never offers (for example PUT or DELETE) to reveal a second flag. It forces you to build a request by hand rather than just clicking.
HTTP is the format of every request and reply. A request has a method (GET, POST, and others), a path, headers (extra info like cookies and content type), and sometimes a body. A response has a status code (200 OK, 302 redirect, 404 not found), its own headers, and a body. Every attack later in this module is just a carefully written HTTP request, so you need to read and write them comfortably.
Any part of a request can be changed by the sender: method, path, headers, cookies, hidden fields, body. Treat all of it as attacker controlled when you design a server.
","quiz":[{"q":"A response is `302` with `Location: /dashboard` and `Set-Cookie: session=abc`. The browser will:","options":["Show an error because 302 is not 200","Store the cookie and send GET /dashboard with it","Ignore the cookie until the next refresh","Resend the original POST to /dashboard"]},{"q":"Which parts of an HTTP request can the sender change with a proxy?","options":["Only visible form fields","Form fields and the URL, but not headers","Everything: method, path, headers, cookies, and body","Nothing once the page has loaded"]}],"lab":{"type":"container","image":"cyberforge/http-basics","objective":"Read the flag from a response header, then send an unlisted HTTP method","needs_flag":true,"needs_code":false}},"output-encoding-csp":{"id":"output-encoding-csp","title":"Output Encoding & CSP","unit":4,"branch":"web","difficulty":3,"prereqs":["xss"],"lab_type":"code","has_quiz":true,"body_html":"The main defense against XSS is output encoding: when you put user data into a page, convert characters like < and > into harmless entities so the browser displays them instead of running them. A Content Security Policy is a second layer that tells the browser which scripts are allowed to run at all, so a missed spot is less likely to be exploitable.
Instead of dropping a comment straight into the HTML, you encode it (< becomes <), so a posted <script> shows up as text. Then you add a header like Content-Security-Policy: default-src 'self' so inline and third party scripts are blocked by default.
Encode for the context you're inserting into: HTML body, HTML attribute, and JavaScript each need different encoding. CSP is defense in depth, not a replacement for encoding.
\nYou're given the vulnerable comment template from the XSS lesson. Add proper output encoding and set a CSP header on the app. Hidden tests rerun the XSS payload and confirm it no longer executes, while normal comments still display correctly.
","short_html":"The main defense against XSS is output encoding: when you put user data into a page, convert characters like < and > into harmless entities so the browser displays them instead of running them. A Content Security Policy is a second layer that tells the browser which scripts are allowed to run at all, so a missed spot is less likely to be exploitable.
Encode for the context you're inserting into: HTML body, HTML attribute, and JavaScript each need different encoding. CSP is defense in depth, not a replacement for encoding.
","quiz":[{"q":"The main defense against XSS is:","options":["Validating input length","Encoding output for the context it's placed in","Blocking the word script","Using HTTPS"]},{"q":"What does a Content Security Policy add on top of encoding?","options":["It encrypts the page","It blocks inline and untrusted scripts as a backup layer","It validates form input","It replaces the need for sessions"]}],"lab":{"type":"code","starter_file":"comments.py","objective":"Encode comment output and add a CSP header","tests":["xss_blocked: the stored payload no longer runs","comments_render: normal text still displays"],"needs_flag":false,"needs_code":true}},"parameterized-queries":{"id":"parameterized-queries","title":"Parameterized Queries","unit":2,"branch":"web","difficulty":2,"prereqs":["sqli"],"lab_type":"code","has_quiz":true,"body_html":"The real fix isn't scrubbing bad characters; it's never mixing data into the query text. A parameterized query sends the SQL and the data separately: the database compiles the query first, then drops the data into fixed slots, so input can never be read as SQL.
\nVulnerable:
\nquery = "SELECT * FROM users WHERE username = '" + user + "'"\ndb.execute(query)Safe:
\nquery = "SELECT * FROM users WHERE username = ?"\ndb.execute(query, (user,))Now a tautology is just a username to search for. No one is named that, so the login correctly fails.
\nPlaceholders bind values, not identifiers. If you ever build a table or column name from user input, you're injectable again; validate those against a fixed allowlist.
\nThe lab ships two versions of login.py: the vulnerable starter and a fix that uses a placeholder. Run the hidden tests on each. On the starter the exploit succeeds and a test fails; on the fix the exploit fails and a valid login still succeeds. All checks passing on the fix completes the lab.
The real fix isn't scrubbing bad characters; it's never mixing data into the query text. A parameterized query sends the SQL and the data separately: the database compiles the query first, then drops the data into fixed slots, so input can never be read as SQL.
\nPlaceholders bind values, not identifiers. If you ever build a table or column name from user input, you're injectable again; validate those against a fixed allowlist.
","quiz":[{"q":"Why does a parameterized query stop SQLi where escaping often fails?","options":["It encrypts the input","The input is never parsed as part of the SQL statement","It blocks the word SELECT","It runs the query as a read only user"]},{"q":"Which is still unsafe even with a parameterized library?","options":["Building a table or column name from user input by string concat","Passing a user's name as a bound parameter","Passing a number as a bound parameter","Using a placeholder for a search term"]}],"lab":{"type":"code","starter_file":"login.py","objective":"Rewrite the login query to use parameters","tests":["exploit_blocked: ' OR '1'='1 fails","normal_login_works: valid creds still succeed"],"needs_flag":false,"needs_code":true}},"path-traversal-uploads":{"id":"path-traversal-uploads","title":"Path Traversal & File Uploads","unit":5,"branch":"web","difficulty":3,"prereqs":["untrusted-input","command-injection"],"lab_type":"container","has_quiz":true,"body_html":"Two related ways to abuse how a server handles files. Path traversal is tricking a file endpoint into reading files outside its intended folder. Insecure file upload is getting the server to accept and later run a file it shouldn't. Both come from trusting a filename or path from the client.
\nA download link uses ?file=report.pdf. If the server just joins that onto a base folder, a ../-laden value climbs out of the folder and returns a system file. On the upload side, a form that only checks for a .jpg extension can be fed a file that's named .jpg but contains server code, which may run if it lands somewhere executable.
For downloads, never build a path from raw input: map an ID to a known filename, or strip and validate the path against a fixed directory. For uploads, verify real content type, rename files, and store them where they can't be executed.
\nTwo parts. Read flag.txt through a ?file= endpoint using ../ traversal, then bypass a naive extension filter to upload a file that reveals a second flag.
Two related ways to abuse how a server handles files. Path traversal is tricking a file endpoint into reading files outside its intended folder. Insecure file upload is getting the server to accept and later run a file it shouldn't. Both come from trusting a filename or path from the client.
\nFor downloads, never build a path from raw input: map an ID to a known filename, or strip and validate the path against a fixed directory. For uploads, verify real content type, rename files, and store them where they can't be executed.
","quiz":[{"q":"A download endpoint uses ?file=report.pdf. What might ?file=../../etc/passwd do?","options":["Return a system file outside the intended folder","Delete the file","Upload a new file","Nothing; .. is always blocked"]},{"q":"An upload form checks only the .jpg extension. Why is that weak?","options":["JPGs cannot be uploaded","A file can be named .jpg but still contain and run server code","The extension changes the file size","It blocks all images"]}],"lab":{"type":"container","image":"cyberforge/path-traversal-uploads","objective":"Read flag.txt via traversal, then bypass the upload filter","needs_flag":true,"needs_code":false}},"session-management":{"id":"session-management","title":"Session Management","unit":3,"branch":"web","difficulty":3,"prereqs":["authentication"],"lab_type":"container","has_quiz":true,"body_html":"After you log in, the session ID is what keeps you logged in. If an attacker can guess, steal, or fix that ID, they become you without ever knowing your password. This is what happens after authentication, so it follows the previous lesson.
\nIf session IDs are handed out in order (user 41 gets session 1041, user 42 gets 1042), an attacker who logs in as themselves can guess the IDs around theirs and hijack other users' sessions. Session fixation is the mirror image: the attacker sets a known ID before the victim logs in, then rides it afterward.
\nSession IDs must be long and random, issued fresh at login (to defeat fixation), sent as HttpOnly Secure cookies, and expired after inactivity.
The app issues sequential session IDs. Log in as a normal user, work out the pattern, and predict the admin's session ID to take over their session and reach the flag.
","short_html":"After you log in, the session ID is what keeps you logged in. If an attacker can guess, steal, or fix that ID, they become you without ever knowing your password. This is what happens after authentication, so it follows the previous lesson.
\nSession IDs must be long and random, issued fresh at login (to defeat fixation), sent as HttpOnly Secure cookies, and expired after inactivity.
Apps store data in a database and fetch it with SQL queries. A query is code; a username is data. Injection happens at the exact moment an app lets data cross into the code half of the query. Before you can exploit or fix that, you need to see where the boundary is in real code.
\nThis builds the query by pasting the name into the string:
\nquery = "SELECT * FROM users WHERE name = '" + name + "'"The programmer wrote the SELECT and the quotes; the name came from a stranger. The database receives one blob of text and can't tell the two apart, so whatever SQL the stranger typed runs as code.
\nThe safe pattern keeps data and query separate using placeholders (Lesson 7). For now, learn to spot concatenation: a + or a formatted string putting input into SQL is the smell.
A search page runs in a debug mode that prints the final SQL it built. Type different inputs and watch your text land inside the query string. The flag unlocks once you submit an input that visibly breaks out of the quotes.
","short_html":"Apps store data in a database and fetch it with SQL queries. A query is code; a username is data. Injection happens at the exact moment an app lets data cross into the code half of the query. Before you can exploit or fix that, you need to see where the boundary is in real code.
\nThe safe pattern keeps data and query separate using placeholders (Lesson 7). For now, learn to spot concatenation: a + or a formatted string putting input into SQL is the smell.
When input crosses into the query, an attacker can rewrite what the query does: log in without a password, read tables they shouldn't, or dump the whole database. SQLi is exploited first here so the fix in the next lesson has meaning.
\nA login runs WHERE username = '$u' AND password = '$p'. Sending a tautology as the username makes the condition always true, so the database returns the first user (often admin) and the attacker is in, no password needed.
Heartland Payment Systems, 2008: a SQL injection led to one of the largest card data breaches of its era, over 100 million transactions exposed.
\nThe fix is parameterized queries (next lesson), not filtering characters. Blocklists for quotes and keywords are routinely bypassed.
\nTwo parts. First, bypass the login. Second, use a UNION SELECT to read a hidden secrets table that has no page of its own. The flag is a row in that table.
When input crosses into the query, an attacker can rewrite what the query does: log in without a password, read tables they shouldn't, or dump the whole database. SQLi is exploited first here so the fix in the next lesson has meaning.
\nThe fix is parameterized queries (next lesson), not filtering characters. Blocklists for quotes and keywords are routinely bypassed.
","quiz":[{"q":"What does ' OR '1'='1 in the username field do to WHERE username='$u' AND password='$p'?","options":["Deletes the users table","Makes the WHERE always true, logging in without a password","Crashes the database","Changes the admin password"]},{"q":"Which behaviour hints the backend is vulnerable to SQLi?","options":["It is slow with long input","A single quote produces a database error","It returns no results for emojis","It lowercases the query"]}],"lab":{"type":"container","image":"cyberforge/sqli-login","objective":"Bypass the login, then UNION dump the hidden secrets table","needs_flag":true,"needs_code":false}},"ssrf":{"id":"ssrf","title":"Server Side Request Forgery","unit":5,"branch":"web","difficulty":4,"prereqs":["http-basics","untrusted-input"],"lab_type":"container","has_quiz":true,"body_html":"SSRF is making the server fetch a URL the attacker chooses. Many apps fetch URLs on your behalf (link previews, webhooks, image fetchers). If the app will fetch any URL, an attacker can point it at internal addresses the attacker can't reach directly, like other services on the private network or a cloud metadata endpoint.
\nA "preview this link" feature fetches whatever URL you paste and shows the result. Paste a link local metadata address or an internal admin URL and the server fetches internal resources and hands you the response, even though those addresses are firewalled off from the outside.
\nDon't let users drive server side fetches freely. Use an allowlist of permitted destinations, block requests to internal and link local IP ranges, and don't reflect raw responses back. Blocklisting strings like localhost is weak because of IP and encoding tricks.
The container runs the public app plus an internal only service on an isolated Docker network. Use the link preview feature to reach the internal service and pull back a flag that the internet facing side can't see directly.
","short_html":"SSRF is making the server fetch a URL the attacker chooses. Many apps fetch URLs on your behalf (link previews, webhooks, image fetchers). If the app will fetch any URL, an attacker can point it at internal addresses the attacker can't reach directly, like other services on the private network or a cloud metadata endpoint.
\nDon't let users drive server side fetches freely. Use an allowlist of permitted destinations, block requests to internal and link local IP ranges, and don't reflect raw responses back. Blocklisting strings like localhost is weak because of IP and encoding tricks.
The single idea behind this whole module: the app trusted something the user sent when it shouldn't have. Input isn't just text boxes. It's URL parameters, headers, cookies, hidden fields, and the body, all chosen by the client. The trust boundary is client versus server, not visible versus hidden.
\nA checkout form carries the price in a hidden field: <input type="hidden" name="price" value="49.99">. It's hidden on the page but fully editable in the request. Change it to 0.01 and, if the server bills what it was sent, the order goes through at a penny.
The server must derive again anything that matters from trusted data it controls. For a price, look it up from the product ID server side; never accept a price the client stated.
\nEdit the hidden price field to buy an item for $0.01. The flag appears on the order confirmation, driving home that hidden is not the same as secure.
","short_html":"The single idea behind this whole module: the app trusted something the user sent when it shouldn't have. Input isn't just text boxes. It's URL parameters, headers, cookies, hidden fields, and the body, all chosen by the client. The trust boundary is client versus server, not visible versus hidden.
\nThe server must derive again anything that matters from trusted data it controls. For a price, look it up from the product ID server side; never accept a price the client stated.
","quiz":[{"q":"Which data should a server treat as untrusted?","options":["Only URL parameters","Form fields and URL parameters, but not headers","Anything from the client: headers, cookies, and hidden fields too","Only data from logged out users"]},{"q":"A hidden field holds a price. The right fix is to:","options":["Mark the field readonly","Base64-encode the price","Look up the price on the server from the product ID","Validate the price in JavaScript"]}],"lab":{"type":"container","image":"cyberforge/untrusted-input","objective":"Edit the hidden price field to check out for $0.01","needs_flag":true,"needs_code":false}},"web-foundations":{"id":"web-foundations","title":"Web Foundations","unit":1,"branch":"web","difficulty":1,"prereqs":[],"lab_type":"container","has_quiz":true,"body_html":"A web app is a conversation between a client (the browser) and a server. You type a URL, the browser finds the server's address through DNS, opens a connection, and asks for a page; the server answers. Knowing which side does what is the whole game in security: the client is fully under the user's control, and the server is the only place a decision can be trusted to be enforced. Everything in this module comes back to that line.
\nVisiting https://shop.example.com/cart runs four steps in order: DNS turns the name into an IP address, TLS sets up an encrypted channel, the browser sends GET /cart, and the server replies with HTML. The page you see is only the server's answer; the request that asked for it was built entirely on your machine, where anyone can change it.
Because the client controls the request, never trust it to enforce rules. Hiding a button or checking a value in JavaScript stops an honest user, not an attacker. Real checks live on the server.
\nThe container serves a small site. Find two flags: one hidden in an HTML comment in the page source, and one in robots.txt. It teaches you to look past the rendered page at what the server actually sent.
A web app is a conversation between a client (the browser) and a server. You type a URL, the browser finds the server's address through DNS, opens a connection, and asks for a page; the server answers. Knowing which side does what is the whole game in security: the client is fully under the user's control, and the server is the only place a decision can be trusted to be enforced. Everything in this module comes back to that line.
\nBecause the client controls the request, never trust it to enforce rules. Hiding a button or checking a value in JavaScript stops an honest user, not an attacker. Real checks live on the server.
","quiz":[{"q":"When you open a URL, what has to happen before any HTTP request is sent?","options":["The server sets a session cookie","DNS resolves the hostname to an IP address","The page's JavaScript runs","The browser renders the HTML"]},{"q":"Which side of the client/server split can a security decision be trusted on?","options":["The client, because the user is signed in","The server, because the client is fully user controlled","Either, as long as HTTPS is used","The client, if the check is in JavaScript"]}],"lab":{"type":"container","image":"cyberforge/web-foundations","objective":"Find the flag in the page source and in robots.txt","needs_flag":true,"needs_code":false}},"xss":{"id":"xss","title":"Cross Site Scripting","unit":4,"branch":"web","difficulty":3,"prereqs":["cookies-sop","untrusted-input"],"lab_type":"container","has_quiz":true,"body_html":"XSS flips the target: instead of attacking the server, you get your script to run in another user's browser. If a site shows user supplied content without neutralizing it, an attacker's script runs with that victim's session, doing whatever the victim could do.
\nA comment box saves whatever you type and shows it to everyone. Post a script tag that reads document.cookie and sends it to an attacker URL, and it runs in every visitor's browser. That's stored XSS; the reflected kind bounces the script off a single response, usually via a crafted link.
The 2005 Samy worm used stored XSS on MySpace to add over a million friends in a day, a classic demonstration of how fast stored XSS spreads.
\nThe fix is in the next lesson: encode output so markup is shown, not run. Note that HttpOnly stops the script from reading the cookie, but the script can still act as the user, so encoding is still required.
The container runs the app plus a simulated "admin bot" (a headless browser) that visits the comments page every few seconds. Post a stored XSS payload that exfiltrates the bot's cookie to a capture endpoint; that cookie is the flag.
","short_html":"XSS flips the target: instead of attacking the server, you get your script to run in another user's browser. If a site shows user supplied content without neutralizing it, an attacker's script runs with that victim's session, doing whatever the victim could do.
\nThe fix is in the next lesson: encode output so markup is shown, not run. Note that HttpOnly stops the script from reading the cookie, but the script can still act as the user, so encoding is still required.