Web exploitation

How websites really work, why you should never trust the browser, and how a single quote mark can log you in as admin.

About 15 minutes · 4 tasks

01How a website really works

When you open a page, your browser sends a text message called a request to a server, and the server sends back a response. That is really all that is happening. Here is one such conversation:

what your browser sends

GET /profile?id=7 HTTP/1.1
Host: shop.challenges.example
Cookie: session=abc123; role=guest

what the server replies

HTTP/1.1 200 OK
Content-Type: text/html

<html> ... your profile page ... </html>

Here is the idea at the heart of web hacking: you control everything in that request. The URL, the id, even the cookie claiming role=guest. The browser is just a convenient tool, and you can send anything you like. Whenever a server trusts something it shouldn't, there is a bug waiting to be found.

02Look before you attack

Lots of Easy web challenges are solved just by looking at what the site already sends you. Check these every time:

Page source and comments. Developers leave notes they think nobody reads.
JavaScript files. Code running in your browser can be read, so anything secret in it isn't secret.
Cookies. Look for readable values like admin=false or something Base64-encoded.
The Network tab. It reveals hidden API calls the page makes behind the scenes.
Common paths. /robots.txt lists places the site asks search engines not to look, which is exactly where you should look. Also try /.git/ and /backup.

Your turn

Practice only: hints are free and nothing here affects your score.

Q1Find the hidden developer note in this page’s source, and submit the flag inside it.

03Changing what you send

Once you have looked around, start changing things. These simple tweaks catch a surprising number of real bugs:

Try this	Example	What it can reveal
Change an id in the URL	`/profile?id=7 → /profile?id=1`	Someone else’s data, if the server never checks that it’s yours
Edit a cookie	`role=guest → role=admin`	Admin features, if the server trusts the cookie
Change a hidden form field	`<input type="hidden" name="price" value="500">`	Buying for 0, if the server trusts the price it receives
Try an unusual request	`POST instead of GET`	Actions that were never meant to be reachable

You can edit cookies in the browser's Application or Storage tab, or send your own with curl:

terminal

curl -b "role=admin" http://shop.challenges.example/admin

Your turn

Practice only: hints are free and nothing here affects your score.

Q2A challenge site sets the cookie is_admin=false, and /admin says "Access denied". What is the first thing to try?
Choose one answerKeep guessing the admin passwordChange the cookie to is_admin=true and reloadAttack the competition platform instead

04SQL injection: your first real exploit

Most websites keep their data in a database and talk to it in a language called SQL. A login page often builds a query by gluing your input into a sentence of SQL:

query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';"

If you type alice and hunter2, the database runs this. It returns a row only if both match, which is what we want:

the query

SELECT * FROM users WHERE username = 'alice' AND password = 'hunter2';

But what if your input contains a quote mark? The quote ends the text early, and whatever you type next becomes part of the SQL command itself. In SQL, -- also starts a comment, so everything after it is ignored. Enter the username alice' -- and look at what the database receives:

the query after injection

SELECT * FROM users WHERE username = 'alice' -- ' AND password = 'anything';

The password check is now inside a comment, so it never runs. You just logged in as alice without her password. This is SQL injection, and it has caused some of the largest data breaches in history.

Try it yourself

There is a user named admin whose password you will never guess. The orange text shows where your input lands in the query. Try logging in as guest with the password guest first, then make it say something it shouldn't.

LabThe vulnerable login

A fake login page and a fake database, both running only inside this page. Nothing is sent anywhere, so break it as much as you like.

Your turn

Practice only: hints are free and nothing here affects your score.

Q3Log in to the fake site as admin without knowing the password, then submit the flag it shows you.
Q4What is the proper way for a developer to prevent SQL injection?
Choose one answerHide the error messagesUse parameterized queriesBan the word SELECT from all input

05Other web bugs to know

Once SQL injection clicks, these will make sense too. They all come down to the same mistake: trusting user input.

Bug	What goes wrong	A first thing to try
Cross-site scripting (XSS)	Your input is shown on a page as code, so it runs in other visitors’ browsers	`<script>alert(1)</script>`
Path traversal	A file name you supply lets you climb out of the intended folder	`?file=../../etc/passwd`
Command injection	Your input is added to a system command, so you can add your own	`127.0.0.1; cat flag.txt`
Server-side request forgery	The server fetches a URL you choose, even internal ones	`?url=http://localhost/admin`
Weak login tokens	A token like a JWT can be read, and sometimes forged	Decode it and see what it claims

To go deeper, the free PortSwigger Web Security Academy(opens in a new tab) has hands-on labs for all of them.

01How a website really works

what your browser sends

GET /profile?id=7 HTTP/1.1
Host: shop.challenges.example
Cookie: session=abc123; role=guest

what the server replies

HTTP/1.1 200 OK
Content-Type: text/html

<html> ... your profile page ... </html>

02Look before you attack

Lots of Easy web challenges are solved just by looking at what the site already sends you. Check these every time:

Page source and comments. Developers leave notes they think nobody reads.
JavaScript files. Code running in your browser can be read, so anything secret in it isn't secret.
Cookies. Look for readable values like admin=false or something Base64-encoded.
The Network tab. It reveals hidden API calls the page makes behind the scenes.
Common paths. /robots.txt lists places the site asks search engines not to look, which is exactly where you should look. Also try /.git/ and /backup.

Your turn

Practice only: hints are free and nothing here affects your score.

Q1Find the hidden developer note in this page’s source, and submit the flag inside it.

03Changing what you send

Once you have looked around, start changing things. These simple tweaks catch a surprising number of real bugs:

Try this	Example	What it can reveal
Change an id in the URL	`/profile?id=7 → /profile?id=1`	Someone else’s data, if the server never checks that it’s yours
Edit a cookie	`role=guest → role=admin`	Admin features, if the server trusts the cookie
Change a hidden form field	`<input type="hidden" name="price" value="500">`	Buying for 0, if the server trusts the price it receives
Try an unusual request	`POST instead of GET`	Actions that were never meant to be reachable

You can edit cookies in the browser's Application or Storage tab, or send your own with curl:

terminal

curl -b "role=admin" http://shop.challenges.example/admin

Your turn

Practice only: hints are free and nothing here affects your score.

Q2A challenge site sets the cookie is_admin=false, and /admin says "Access denied". What is the first thing to try?
Choose one answerKeep guessing the admin passwordChange the cookie to is_admin=true and reloadAttack the competition platform instead

04SQL injection: your first real exploit

Most websites keep their data in a database and talk to it in a language called SQL. A login page often builds a query by gluing your input into a sentence of SQL:

query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "';"

If you type alice and hunter2, the database runs this. It returns a row only if both match, which is what we want:

the query

SELECT * FROM users WHERE username = 'alice' AND password = 'hunter2';

the query after injection

SELECT * FROM users WHERE username = 'alice' -- ' AND password = 'anything';

Try it yourself

LabThe vulnerable login

A fake login page and a fake database, both running only inside this page. Nothing is sent anywhere, so break it as much as you like.

Your turn

Practice only: hints are free and nothing here affects your score.

Q3Log in to the fake site as admin without knowing the password, then submit the flag it shows you.
Q4What is the proper way for a developer to prevent SQL injection?
Choose one answerHide the error messagesUse parameterized queriesBan the word SELECT from all input

05Other web bugs to know

Once SQL injection clicks, these will make sense too. They all come down to the same mistake: trusting user input.

Bug	What goes wrong	A first thing to try
Cross-site scripting (XSS)	Your input is shown on a page as code, so it runs in other visitors’ browsers	`<script>alert(1)</script>`
Path traversal	A file name you supply lets you climb out of the intended folder	`?file=../../etc/passwd`
Command injection	Your input is added to a system command, so you can add your own	`127.0.0.1; cat flag.txt`
Server-side request forgery	The server fetches a URL you choose, even internal ones	`?url=http://localhost/admin`
Weak login tokens	A token like a JWT can be read, and sometimes forged	Decode it and see what it claims

To go deeper, the free PortSwigger Web Security Academy(opens in a new tab) has hands-on labs for all of them.