Lab 04 — Natas 0 to 5: your first web hacking

Level 0's page says the password is on this page. It is — just not in the part the browser draws. It is sitting in an HTML comment, which renders as nothing.

# View the raw HTML: Ctrl-U, or right-click → View Page Source

what you are looking for looks like this

<!-- the password for natas1 is ... -->

The browser hides comments; it does not remove them. Anything between <!-- and --> is invisible on the page and fully present in the response. Developers leave notes, old code, and—too often—credentials in there, forgetting the visitor gets the whole file, comments and all. “View Source” is the first thing anyone curious does to a web page, and level 0 is teaching you to do it reflexively.

Level 1 is the same trick as level 0 — password in a comment — with one addition: right-clicking has been disabled, so you cannot reach “View Source” the easy way. This obstacle is the entire lesson.

# Ctrl-U still works — the keyboard shortcut ignores the right-click block

or open dev tools (F12) and read the Elements panel,
or just disable JavaScript and right-click normally

The block runs in your browser, which means you own it. A script disabling the context menu is JavaScript the server sent to your machine and asked nicely to run. You are under no obligation to obey it. Ctrl-U, dev tools, turning JavaScript off, or fetching the page with curl all sail straight past it.

This is one of the most common real-world mistakes there is. “Disable right-click to protect the content”, form validation that only happens in the browser, a checkout that trusts a price sent by the page — all the same error. Any control that runs on the attacker's device is a suggestion, not a lock. Natas 1 is where that stops being abstract.

Level 2 says there is nothing on this page — and the visible page really is empty. But the source has one <img> tag pointing at a tiny image in a folder called files.

# The source references  /files/pixel.png  — so visit the folder itself:

http://natas2.natas.labs.overthewire.org/files/

if the server lists the folder's contents, read what else is in there

Two failures stacked, and both are real. First, a supposedly empty page still gives away a path, because the image it loads has to live somewhere. Second, that folder has directory listing switched on — ask for a folder with no index page and the server hands you a clickable list of everything in it. Neither is a bug in isolation; together they hand you a file you were never meant to see.

Chasing paths that leak from a page — in image tags, in scripts, in comments — and then checking whether their directories are browsable is bread-and-butter web recon. An open listing on a real site is where backups, config files and credential dumps get found.

Level 3 also looks empty, but the source carries a comment sneering that not even Google will find it this time. That is a direct pointer, if you know what tells Google where not to look.

# Check the file that talks to search engines:

http://natas3.natas.labs.overthewire.org/robots.txt

it names a directory it wants crawlers to skip. go look in that directory.

robots.txt is a request to crawlers, not a lock on a door. It lists paths that well-behaved search engines agree to skip — and in doing so it publishes those exact paths, in a file anyone can read, at a location that never changes. A Disallow: line is a signpost saying “something here I would rather you not see”.

Reading a target's robots.txt is step one of web reconnaissance for exactly this reason. Admins routinely list their admin panels, staging directories and backup folders in it, trying to keep them out of Google, and hand every attacker a map in the process.

Level 4 refuses you outright: access is only for visitors coming from a particular page, it says, and quotes back the empty place where your referring page should be. It is telling you exactly which header it checks.

$ curl -u natas4:PASSWORD -H "Referer: http://natas5.natas.labs.overthewire.org/" http://natas4.natas.labs.overthewire.org/

note the authorised page is natas5, not natas4 — read the message carefully.
no curl? use Burp, or your browser's Network tab → Edit and Resend.

The Referer header says where you came from — and your browser sets it, so you can set it to anything. The server is making an access decision based on a value the visitor completely controls, which means it is making no real decision at all. Forge the header, and the door opens. (The misspelling “Referer” is a thirty-year-old typo baked into the HTTP standard; it is correct.)

Trusting client-controlled input for authorisation is a whole category of real vulnerability. Referer, User-Agent, X-Forwarded-For, a hidden form field — anything the client sends, the client can change. The rule you are learning: authenticate on the server, with something the client cannot forge.

Level 5 says you are not logged in. There is no form and no obvious way to log in — because the server is deciding your status from a cookie it set in your browser, and cookies are just text you can edit.

# Open dev tools → Application (or Storage) → Cookies

you will find a cookie named  loggedin  set to  0
change it to  1  and reload the page

or from the command line:
$ curl -u natas5:PASSWORD -b "loggedin=1" http://natas5.natas.labs.overthewire.org/

A cookie lives in your browser, so you decide what it says. The server set loggedin=0 and then trusted its own cookie to still say that when you came back. But nothing stops you opening the cookie jar and changing the 0 to a 1. There was no check that the value had not been tampered with.

This is why real sessions are signed or random. A modern app stores a long unguessable session ID, or a cryptographically signed token, precisely so that editing it gets you rejected rather than promoted. A cookie that says loggedin=1 in plain text, with no signature, is trusting the attacker to be honest. Natas 5 is the last brick in the wall the first six levels build: never trust anything the client can change.