How the internet works

Before you can understand how websites are broken into, you need to understand how they work. Every vulnerability you will learn later is, in the end, a message sent in a way nobody expected. In this lesson we follow one request from your device to a website and back.

Client and server

The internet is a network of devices exchanging messages. In most of what you will deal with there are two sides:

• The client: the program that asks, usually your browser.
• The server: the machine that waits for requests and answers them. It holds the site’s files and data.

The browser does not “open” a website. It sends a request, the server answers with files, and the browser draws them on the screen.

Addresses: IP and DNS

Every device on the network has a numeric address called an IP addressA number that identifies a device on the network, such as 203.0.113.10. Messages are routed to it the way a letter is routed to a street address.. People remember names, not numbers, which is why the Domain Name System (DNS) exists.

When you type example.com, your device asks a DNS server: what is the IP address for this name? It then uses the number that comes back to contact the server. You can watch this happen yourself:

# ask DNS for the domain's address
nslookup example.com

Ports and protocols

One server can run several services at once: a website, mail, remote access. To tell them apart, each one uses a different portA number from 0 to 65535 that says which service on the machine receives the message. The IP address gets you to the building; the port gets you to the apartment..

A protocol is the agreed language for what messages look like. The browser and the server talk to each other in HTTP, which is the subject of the next lesson.

The journey of one request

When you type https://example.com/about and press Enter, this happens in order:

1. The browser asks DNS for the IP address of example.com.
2. It opens a connection to that address on port 443.
3. Both sides agree on how to encrypt the connection. That is what the S in HTTPS means.
4. The browser sends an HTTP request saying: I want the page /about.
5. The server answers with a status code and the page content.
6. The browser reads the content, requests the images and files it needs, then draws the page.

The request in step four is plain text you can read:

GET /about HTTP/1.1
Host: example.com
User-Agent: ExampleBrowser/1.0

Why this matters for security

Every step of this journey is a place where something can go wrong:

• If the server trusts everything in the request without checking it, an attacker can write a request the programmer never expected. This is the root of vulnerabilities such as SQL Injection and XSS.
• If the connection is not encrypted, anyone sitting in the middle can read the messages.
• If a port is left open for a forgotten service, it becomes one more door into the server.