Web Server

Before we can attack web applications, we need to understand the infrastructure that serves them.

When a user visits a website, their browser is not communicating directly with source code. Instead, the request usually passes through multiple layers of infrastructure:

User -> DNS -> Web Server -> Application -> Database

Understanding where each component lives is critical for both attackers and defenders.

---

What Is a Web Server?

A web server is software that listens for HTTP or HTTPS requests and returns responses.

Common examples include:

A web server's primary job is to:

• Accept connections
• Parse HTTP requests
• Serve content
• Forward requests to applications

---

Example

A user visits:

https://portal.corp.local/login

The browser sends:

GET /login HTTP/1.1

The web server receives the request and decides what to do.

Possible outcomes:

• Return a static HTML page
• Return an image
• Execute application code
• Forward the request elsewhere

---

Static Content

Some files are served directly by the web server.

Examples:

• HTML
• CSS
• JavaScript
• Images
• Videos

Example:

GET /logo.png

The server simply reads:

/var/www/html/logo.png

and returns it.

No application code executes.

These types of websites have a smaller direct attack surface because no server-side application code executes for each request, but they are not immune to security issues. Exposed files, misconfigured hosting, weak headers, vulnerable JavaScript dependencies and CDN or storage misconfigurations can still matter. You can often infer this behavior by observing the website and the responses it returns - for example, if it only returns static elements such as .html pages or images.

---

Dynamic Content

Modern websites rarely consist entirely of static files.

Instead, requests are usually processed by an application.

Example:

GET /account

The server forwards the request to:

• PHP
• ASP.NET
• Java
• Node.js
• Python
• Go

The application performs logic and generates a response.

These websites are the ones pentesters are usually more interested in and require special attention, especially around the components which receive direct user input, since it could generally influence the underlying execution. User input sanitization and validation is a very important (and broad) topic, which will be explored later on. For now we are still building foundations.

---

Typical Architecture

            Internet
                |
                v
         +-------------+
         |   NGINX     |
         +-------------+
                |
                v
         +-------------+
         | Application |
         +-------------+
                |
                v
         +-------------+
         |  Database   |
         +-------------+

The web server acts as the front door.

The application performs business logic.

The database stores data.

The user never communicates directly with the application.

Benefits:

• Load balancing
• TLS termination
• Caching
• Request filtering
• Hiding backend infrastructure

Many modern environments place a reverse proxy in front of every application.

---

Why Attackers Care

Web servers often expose:

• Login portals
• APIs
• Internal applications
• Administrative interfaces

Compromising a web application often provides:

• Initial access
• Sensitive data
• Credentials
• Remote code execution

Many real-world breaches begin with a vulnerable web application.

---

Virtual Hosts

A single server can host many websites.

Example:

203.0.113.10

may host:

• portal.corp.local
• hr.corp.local
• vpn.corp.local

The web server determines which site to serve based on the Host header.

Example:

Host: portal.corp.local

This concept is important during enumeration because additional websites may exist on the same IP address.

---

Application Servers

The web server and the application are often separate.

Examples:

A compromise of one does not automatically imply compromise of the other.