A bakery website that overshares
A small bakery has a website with its opening times and price lists. It works, and customers like it.
But the server tells every visitor which software it runs, down to the version. It will answer an admin page to anybody who types the address. Nobody set it up to be careless. Nobody told it to be careful, either.
The one rule
Warning
This lab is a web server that is weak on purpose. Work only on your own private copy, with your teacher's permission. It has no way out to the internet. Probing a server that is not yours is a crime under the Computer Misuse Act 1990. We look for weak settings so we can fix them.
By the end of this lesson
Note
I can harden a web server.
Key words
| Word | What it means | Example |
|---|---|---|
| Web server | a program that sends web pages to browsers | nginx |
| Hardening | changing settings so a system gives away and allows less | |
| Header | a line at the top of a reply that describes it | Server: nginx |
| Status code | a three-digit number saying how a request went | 404 |
| Policy | a written list of what must be true |
The cells students fill in are left blank in this preview.
Before you start
Note
Press Start the lab on the bar at the top. Your lab has a bakery website on a server called web, and a terminal beside it. Each Run types its command into that terminal. The Runs in this lesson only ask the server questions. They change nothing.
Every reply starts with headers
When your browser asks for a page, the server's reply starts with headers. The browser reads them, and you never see them.
The curl -I command asks for the headers only. The first line is the status. Each line after it is a name, a colon and a value.
Some headers are useful. Some give away too much. Look at the Server line.
Read the bakery server's headers
curl -s -I http://webShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Worked example: what the headers say
| Line it printed | What it tells a visitor | A problem? |
|---|---|---|
| HTTP/1.1 200 OK | The page was found | No |
| Server: nginx/1.27.5 | The exact software and version | Yes: an attacker can look up its known flaws |
| Content-Type: text/html | The reply is a web page | No |
| Date and Last-Modified | When it was sent and last changed | No |
The cells students fill in are left blank in this preview.
A hardened server refuses what it should
The status code says how a request went. 200 means here it is. 404 means not found. 405 means that method is not allowed here. 401 and 403 mean you may not have it.
A careless server answers 200 to too much. A hidden page is not a locked page: anybody can type its address. These three Runs print only the status code.
Ask for a page that does not exist
curl -s -o /dev/null -w "%{http_code}\n" http://web/nothing-hereShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Ask the server to delete its home page
curl -s -o /dev/null -w "%{http_code}\n" -X DELETE http://web/Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Ask for the admin page as a stranger
curl -s -o /dev/null -w "%{http_code}\n" http://web/admin/Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A common mistake
Warning
Many people think a page with no link to it is safe, because nobody can find it. A server answers any address that is typed, and attackers try common ones like /admin/. Protect a private page with a sign-in or a network limit, so the server refuses it.
A policy turns good habits into a checklist
A business writes its rules down as a policy, so every server can be checked the same way. A web server policy often says four things.
Hide the version. Never list a folder's files. Refuse private pages to strangers. Send the protective headers, such as Content-Security-Policy, which limits which scripts a page may run.
The next Run counts how many times that header appears.
Is the protective header sent?
curl -s -I http://web | grep -ci "content-security-policy"Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Going further: your own before and after
When you have made the lab's fixes, run curl -s -I http://web again. Copy the header lines into a list, leaving out the status line.
Pass the list before and after to check_policy from your assignment, with Content-Security-Policy and X-Frame-Options in the policy. Write one sentence on what changed and why it matters.