How the Internet Works: A Hacker’s Primer

Before jumping into hunting for bugs, it’s essential to understand how the internet works. Finding web vulnerabilities is all about exploiting weaknesses in this technology, so all successful hackers should have a solid understanding of its core components and protocols.

Let’s explore what happens, for instance, when you enter www.google.com in your browser, starting with the fundamental model of web communication.

The Client-Server Model

The internet is fundamentally composed of two types of devices: clients and servers.

• Clients: Request resources or services. Your browser (Chrome, Firefox, Safari) acts as the client when you visit a website.
• Servers: Provide those resources and services. The web server hosts the website files.

When your browser requests a web page from a web server, the server sends the required files back to the browser.

Web Page Resources

A web page is a collection of files, or resources, sent by the web server:

• Hypertext Markup Language (HTML): A text file that provides the structure and content, telling your browser what to display.
• Cascading Style Sheets (CSS): Files used to format the visual appearance of the web page (to “make them pretty”).
• JavaScript (JS): Files that enable sites to animate the web page and react to user input without going through the server (client-side validation).
• Embedded Resources: Such as images and videos.

Your browser combines these resources to display the final web page you see.

Web APIs

Servers don’t just return web pages; they also use Web APIs (Application Programming Interfaces). APIs enable applications to request data from other systems, allowing them to interact and share data in a controlled way. For example, Twitter’s APIs allow other websites to send requests to Twitter’s servers to retrieve data like public tweets.

Naming and Addressing on the Internet

The Domain Name System (DNS)

Every device connected to the internet has a unique Internet Protocol (IP) address that other devices use to find it. However, IP addresses (like the older IPv4 format: 123.45.67.89 or the more complicated IPv6 format: 2001:db8::ff00:42:8329) are hard for humans to remember.

The Domain Name System (DNS) resolves this issue. A DNS server functions as the phone book for the internet, translating memorable domain names (like google.com) into their corresponding IP addresses. When you enter a domain name, your browser first queries a DNS server to get the IP address.

Internet Ports

After the browser acquires the correct IP address, it connects to that address via a port. A port is a logical division on a device that identifies a specific network service. Ports are identified by numbers ranging from 0 to 65,535.

Ports allow a server to provide multiple services simultaneously. Port numbers help the server quickly forward incoming internet messages to the corresponding service for processing.

• By default, port 80 is used for HTTP (unencrypted web traffic).
• Port 443 is used for HTTPS (the encrypted version of HTTP).

HTTP Requests and Responses

Once a connection is established (usually to port 80 or 443), the browser and server communicate using the HyperText Transfer Protocol (HTTP). HTTP specifies the rules for structuring and interpreting internet messages.

HTTP Requests

When a browser wants to interact with a server, it sends an HTTP request. The two most common request types (methods) are:

• GET: Used by convention to retrieve data from the server (e.g., asking for a web page).
• POST: Used by convention to submit data to the server (e.g., submitting a login form).

Other common methods include OPTIONS, PUT (update a resource), and DELETE (delete a resource).

Request Structure

All HTTP requests are composed of three parts: a request line, request headers, and an optional request body.

1. Request Line: The first line, specifying the request method, the requested URL (path), and the HTTP version (e.g., GET / HTTP/1.1).
2. Request Headers: Used to pass additional information about the request to the server, allowing the server to customize results. Common headers include:
   • Host: Specifies the domain name.
   • User-Agent: Contains the operating system and software version of the requesting software (the browser).
   • Accept, Accept-Language, Accept-Encoding: Tell the server which response formats the client can handle.
   • Cookie: Used to send cookies from the client to the server (crucial for session management).
   • Referer: Specifies the URL of the previous page that linked to the current page.
   • Authorization: Contains credentials to authenticate a user.
3. Request Body (Optional): Used primarily with POST requests to carry the submitted data.

HTTP Responses

After receiving the request, the server tries to fulfill it and returns an HTTP response.

Response Components

1. HTTP Status Code: A three-digit number indicating whether the request succeeded (e.g., 200 OK).
2. HTTP Headers: Bits of information passed from the server to the client about authentication, content format, and security policies. Common headers include:
   • Set-Cookie: Sent by the server to the client to set a cookie.
   • Location: Indicates the URL to which to redirect the page (for $300$ status codes).
   • Content-Type: Indicates the file type of the response body (e.g., text/html).
   • Access-Control-Allow-Origin: Indicates which origins can access the page’s content (related to CORS).
   • Content-Security-Policy and X-Frame-Options: Control security-related browser behavior.
3. HTTP Response Body: The actual web content requested, such as HTML code, CSS, JavaScript, or images.

Status Codes: A Hacker’s Focus

As a bug bounty hunter, you should always monitor status codes:

• $200$ range: Successful request.
• $300$ range: Redirect to another page.
• $400$ range: Client-side error (e.g., 403 Forbidden—access denied, or 404 Not Found).
• $500$ range: Server-side error.

A status code of 403 Forbidden is particularly interesting, as it suggests sensitive data may be hidden on the page that could be reached if you can bypass the access controls.

Internet Security Controls

To hunt for bugs effectively, you need to understand the fundamental security controls in place, as your goal is often to find creative ways to bypass these controls.

Content Encoding

Data transferred in HTTP requests and responses is often encoded to prevent data corruption and reliably transfer binary data across machines.

• Base64 Encoding: One of the most common encoding schemes, used to transport images and encrypted information. It uses uppercase letters (A–Z), lowercase letters (a–z), numbers (0–9), +, /, and = for padding. Base64url is a modified version for URL format.
  • Example: "Content Encoding" becomes Q29udGVudCBFbmNvZGluZw==
• Hex Encoding (Hexadecimal): Represents characters in a base-$16$ format (0 to F). It’s less efficient but more human-readable than Base64.
  • Example: "Content Encoding" becomes 436f6e74656e7420456e636f64696e67
• URL Encoding (Percent-Encoding): Converts characters into a format easily transmitted over the internet by representing each character with its hex number preceded by a % symbol.
  • Example: localhost becomes %6c%6f%63%61%6c%68%6f%73%74

Tip for Hackers: When you see encoded content, always try to decode it using tools like Burp Suite’s decoder or CyberChef to discover what the website is trying to communicate, as this can often reveal hidden parameters or data.

Servers sometimes also encrypt their content before transmission to keep the data private between the client and server.

Session Management and HTTP Cookies

Session management is the process that allows the server to handle multiple requests from the same user without asking them to log in again.

1. When you log in, the server creates a session for you.
2. The server assigns a unique, long, and unpredictable session ID that serves as proof of your identity.
3. Most websites use HTTP cookies to communicate this session information. The server sends the session ID to your browser as a cookie using the Set-Cookie response header.
4. Your browser stores the cookie and includes it in every subsequent request to the same server via the Cookie request header.
5. The server uses the session ID in the cookie to validate your identity.

When you log out, the server ends the session and revokes (invalidates) the session ID.

Token-Based Authentication

In a token-based authentication system, the user’s identity information is stored directly within a token, rather than stored server-side and queried using a session ID. This prevents applications from having to store and maintain session information server-side.

• Integrity Protection: To prevent token forgery (where an attacker modifies the token), applications often sign the token using a secret key known only to the server. The server verifies this signature upon receiving the token. A valid signature suggests the token has not been altered by the client or a third party.

JSON Web Tokens (JWTs)

The JSON Web Token (JWT) is a common type of token. It consists of three parts, separated by a period (.):

$$
\text{Header}.\text{Payload}.\text{Signature}
$$

1. Header: A Base64URL-encoded string identifying the signature algorithm used (e.g., HS256).
2. Payload: A Base64URL-encoded string containing information about the user’s identity (e.g., {"user\_name" : "admin"}). If the token is not encrypted, anyone can decode the payload, making it a potential source of information leaks.
3. Signature: Calculated by signing the concatenated Header and Payload using the specified algorithm and a secret key.

When implemented correctly, the server verifies the signature to ensure integrity and then decodes the payload to deduce the user’s identity.

JWT Security Issues (Implementation Flaws)

If JWTs are implemented incorrectly, attackers can forge arbitrary tokens:

• Manipulating the alg Field (Algorithm Confusion):
  • alg: none Attack: If the application fails to restrict the algorithm type, an attacker can set the alg field to none. This forces the server to accept tokens with an empty signature section as valid.
  • HMAC/RSA Confusion: If an application expects an RSA token (signed with a private key, verified with a public key), an attacker might change the alg field to HMAC. If the application then tries to verify the HMAC token using the RSA public key (which is publicly available) as the symmetric HMAC key, the attacker can sign their forged token with that same public key and bypass authentication.
• Brute-Forcing or Leaking the Key: If the secret key used to sign the token is not complex enough, an attacker might brute-force it. They might also attempt to leak the secret key using other vulnerabilities (like directory traversal, XXE, or SSRF) if the key value is stored in a file they can read.

The Same-Origin Policy (SOP)

The Same-Origin Policy (SOP) is a crucial security rule that restricts how a script from one origin can interact with the resources of a different origin.

The Rule: A script from page A can access data from page B only if the pages are of the same origin.

Two URLs have the same origin if they share the same protocol, hostname, and port number.

SOP’s Protection: SOP prevents a malicious script (e.g., on attacker.com) from reading sensitive data (like banking information) returned from a different origin (e.g., onlinebank.com), even if the user is logged into both sites and their session cookies are sent with the request.

Learn to Program

Before or during your hacking journey, it is highly recommended that you learn to program.

• Automation: Hunting for bugs involves many repetitive tasks. Learning a programming language like Python or shell scripting allows you to automate these tasks, saving significant time.
• Code Reading: You should also learn to read JavaScript, the language most sites are written in. Reading a site’s JavaScript can quickly reveal hidden endpoints, insecure programming logic, and secret keys—a “secret sauce” many top hackers utilize.

Resources like Codecademy for general programming, Learn Python the Hard Way by Zed Shaw (Addison-Wesley Professional, 2013), and Eloquent JavaScript, Third Edition, by Marijn Haverbeke (No Starch Press, 2019) are excellent starting points.