ExamFinch.com My Study

Study guide

10.2 Web Application Components, Frameworks & State Management

Practice this exam

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

10.2 Web Application Components, Frameworks & State Management

Key Takeaways Explain This Topic AI

Web applications separate presentation, business logic, and data storage into distinct architectural tiers, requiring strict server-side validation because client-side controls are easily bypassed with intercepting proxies.

Enterprise execution environments (Java EE, ASP.NET, Node.js, Python WSGI/ASGI, PHP) process application state differently, introducing specific risks such as insecure deserialization or unauthenticated ViewState tampering.

Because HTTP is inherently stateless, session identifiers maintain state across requests and must possess at least 128 bits of entropy generated by a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG).

Proper session lifecycle management requires enforcing both idle and absolute timeouts, invalidating sessions server-side upon logout, and re-issuing fresh session identifiers upon authentication to mitigate session fixation attacks.

Cookie security flags are foundational defensive controls: Secure prevents cleartext sniffing over HTTP, HttpOnly prevents XSS-based JavaScript theft, and SameSite (Strict/Lax) mitigates Cross-Site Request Forgery (CSRF).

Last updated: September 2026

10.2 Web Application Components, Frameworks & State Management

Modern web applications have evolved from simple static document delivery systems into sophisticated distributed software platforms. Behind every interactive web service lies a web technology stack comprising front-end presentation scripts, server-side execution engines, application frameworks, object-relational mappers, and backend datastores. For security analysts assessing web applications, understanding how these components communicate, where state is maintained, and how trust boundaries are enforced is critical for identifying vulnerabilities in application logic and session handling.

Multi-Tier Enterprise Application Architectures

Enterprise software design relies on layered architectures to separate user interaction from business calculations and database persistence. +-----------------------------------------------------------------------------+

  • | THREE-TIER ENTERPRISE ARCHITECTURAL MODEL |
  • +-----------------------------------------------------------------------------+
  • | 1. PRESENTATION TIER |
  • | Client Browser DOM, HTML5, CSS, React, Vue, Angular, Mobile Apps |
  • | Untrusted boundary: all data originating here must be treated as hostile |
  • +-----------------------------------------------------------------------------+
  • | (JSON, XML, Form Data over HTTPS)
  • v
  • +-----------------------------------------------------------------------------+
  • | 2. APPLICATION LOGIC TIER |
  • | Controllers, Services, API Endpoints, Business Rules Engine |
  • | Runtimes: Java EE (Tomcat), .NET (CLR), Node.js, Python WSGI, PHP |
  • | Enforces authentication, authorization, validation, and session state |
  • +-----------------------------------------------------------------------------+
  • | (Database Connectors, ORM, SQL, NoSQL)
  • v
  • +-----------------------------------------------------------------------------+
  • | 3. DATA PERSISTENCE TIER |
  • | Relational Databases (PostgreSQL, Oracle, MSSQL), NoSQL (MongoDB, Redis) |
  • | Houses persistent business records, credential hashes, and audit tables |
  • +-----------------------------------------------------------------------------+
  • Application Runtimes & Framework Taxonomies

Different programming runtimes handle execution, concurrency, and state persistence in unique ways, each presenting distinct security considerations during an assessment.

Runtime Stack Core Components & Architectures Packaging / Deployment Distinct Security Considerations

Java Enterprise (Jakarta EE) Java Virtual Machine (JVM), Servlets, JSP, Spring Boot, Struts, Hibernate. Application servers: Apache Tomcat, Eclipse Jetty, JBoss/WildFly, WebLogic. .war (Web Application Archive), .ear (Enterprise Archive), executable JARs. Vulnerable to Insecure Deserialization (readObject gadget chains), Expression Language (EL) injection, and XML External Entity (XXE) processing.

Microsoft .NET / ASP.NET Common Language Runtime (CLR), ASP.NET Web Forms, ASP.NET Core MVC, Entity Framework. Hosted in IIS worker processes ( w3wp.exe ). Compiled DLL assemblies, NuGet packages. Heavy reliance on ViewState in legacy Web Forms; insecure deserialization via BinaryFormatter ; MachineKey tampering leading to Remote Code Execution (RCE).

Node.js Google V8 JavaScript engine, single-threaded asynchronous event loop, non-blocking I/O. Frameworks: Express.js, Fastify, NestJS. npm / yarn packages, JavaScript bundles. Single-threaded architecture makes it vulnerable to Event Loop Starvation (Denial of Service via ReDoS); Prototype Pollution; supply-chain vulnerabilities in npm.

Python WSGI / ASGI Python interpreter, WSGI (synchronous: Django, Flask), ASGI (asynchronous: FastAPI, Starlette). App servers: Gunicorn, uWSGI, Uvicorn. Virtual environments, pip wheels. Template injection in Jinja2/Django templates (SSTI); debug consoles exposed in production (Werkzeug PIN bypass); ORM injection when using raw SQL clauses.

PHP Interpreted Zend Engine, PHP-FPM (FastCGI Process Manager), Apache mod_php . Frameworks: Laravel, Symfony, WordPress. Standalone .php scripts, Composer dependencies. Legacy configuration pitfalls ( allow_url_include leading to RFI); type juggling in loose comparisons ( == vs === ); Local File Inclusion (LFI); object injection via unserialize() .

Client-Side vs. Server-Side Execution

A critical concept in web security is the distinction between code executing within the client's browser and code executing on the server. +-----------------------------------------------------------------------------+

  • | CLIENT-SIDE VS. SERVER-SIDE EXECUTION BOUNDARY |
  • +-----------------------------------------------------------------------------+
  • | [Client Browser: Untrusted Zone] [Web / App Server: Trusted Zone] |
  • | | |
  • | - HTML5 Form Regex Validation | |
  • | - JavaScript Input Restrictions | HTTP POST Request |
  • | - Disabled 'Submit' Buttons | ----------------------> Raw Payload |
  • | - Hidden Form Fields (<input>) | (Bypasses all client Received |
  • | - Client-side Captcha Checks | validations via Directly |
  • | | Burp Suite / Proxy) |
  • | | |
  • | | Server MUST Re-validate: |
  • | | - Type, length, format (Regex) |
  • | | - Business logic boundaries |
  • | | - Authorization & session validity |
  • +-----------------------------------------------------------------------------+
  • The Golden Rule of Web Application Security

Client-side validation is a user experience (UX) enhancement, NEVER a security boundary.

Client-side validation (implemented in HTML5 attributes such as required , pattern="[0-9]+" , maxlength="10" , or JavaScript event listeners) provides immediate feedback to users, preventing accidental typographic errors before a request is submitted. However, because the client environment is completely under the attacker's control, any client-side protection can be circumvented trivially by:

Intercepting the HTTP request using an intercepting web proxy (e.g., Burp Suite, OWASP ZAP, Caido) and altering parameter values after validation has executed.

Disabling JavaScript in the browser settings.

Submitting custom raw requests directly using command-line utilities such as curl , httpie , or custom Python scripts.

Modifying client-side variables, DOM elements, or JavaScript functions directly within browser developer tools (F12 Console).

Consequently, all security-critical validation, business rule enforcement, and authorization checks must execute authoritatively on the server .

State Management & Session Handling

The HTTP protocol is fundamentally stateless —by default, the server processes every incoming request in complete isolation, retaining no inherent memory of previous interactions. To facilitate stateful workflows (such as maintaining a user's authenticated identity, shopping cart items, or multi-step wizard progress), web applications must implement state management mechanisms . +-----------------------------------------------------------------------------+

  • | STATE MAINTENANCE MECHANISMS |
  • +-----------------------------------------------------------------------------+
  • | Mechanism | Storage Location | Security Posture |
  • +------------------+------------------+---------------------------------------+
  • | HTTP Cookies | Client Browser | Secure if hardened with flags; |
  • | | | susceptible to XSS / CSRF if flawed |
  • | URL Rewriting | Query Parameters | High Risk: Tokens leak in server |
  • | | (?sessionid=...) | logs, Referer headers, browser history|
  • | Hidden Fields | HTML Body | Tamperable by client; requires |
  • | | (<input hidden>) | cryptographic integrity (e.g., HMAC) |
  • +-----------------------------------------------------------------------------+
  • Properties of Secure Session Tokens

A session identifier (Session ID) acts as a temporary credential substituting for the user's username and password for the duration of the session. If an attacker acquires or predicts a valid session ID, they can impersonate the authenticated victim entirely without knowing the user's password.

To ensure resilience against attacks, session identifiers must meet four essential criteria:

Cryptographic Randomness & Entropy: Session IDs must be generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) , such as /dev/urandom on Unix, java.security.SecureRandom in Java, or crypto.randomBytes() in Node.js. Session tokens must provide a minimum of 128 bits of entropy (16 bytes of random data), rendering offline or online brute-force guessing mathematically infeasible.

Unpredictability: Tokens must not follow sequential patterns, timestamp-based algorithms, or incorporate predictable user metadata (such as Base64-encoded usernames or incrementing database integers).

Uniqueness: The token space must be vast enough that the probability of generating duplicate active tokens across millions of concurrent users is effectively zero.

Opaque Structure: Session IDs should preferably be opaque strings that disclose no internal system information or user permissions.

Session Lifecycle Management

A secure session lifecycle enforces strict boundaries from generation through termination: +-----------------------------------------------------------------------------+

  • | SECURE SESSION LIFECYCLE |
  • +-----------------------------------------------------------------------------+
  • | 1. PRE-AUTHENTICATION |
  • | Anonymous visitor receives unprivileged session ID or no session |
  • +-----------------------------------------------------------------------------+
  • |
  • v [User submits valid credentials]
  • +-----------------------------------------------------------------------------+
  • | 2. AUTHENTICATION & RE-ISSUANCE |
  • | CRITICAL: Application invalidates pre-login session ID |
  • | Issues completely fresh, cryptographically strong session ID |
  • | (Mitigates Session Fixation) |
  • +-----------------------------------------------------------------------------+
  • |
  • v [Periodic requests / Inactivity]
  • +-----------------------------------------------------------------------------+
  • | 3. TIMEOUT CONTROLS |
  • | - Idle Timeout: Expires session after 15-30 minutes of user inactivity |
  • | - Absolute Timeout: Forces re-authentication after 8-12 hours maximum |
  • +-----------------------------------------------------------------------------+
  • |
  • v [User clicks 'Logout']
  • +-----------------------------------------------------------------------------+
  • | 4. TERMINATION |
  • | Server explicitly destroys session record in datastore/cache |
  • | Instructs browser to overwrite cookie with expired Set-Cookie header |
  • +-----------------------------------------------------------------------------+
  • Primary Session Flaws

Session Hijacking: An attacker steals an active, legitimate session token belonging to an authenticated user. Theft vectors include unencrypted HTTP network sniffing (Man-in-the-Middle), Cross-Site Scripting (reading unhardened cookies via document.cookie ), proxy/server log leakage, or malware.

Session Fixation: Occurs when an application does not re-issue a new session identifier upon successful authentication. An attacker obtains an unauthenticated session ID (e.g., SID=12345 ) and tricks a victim into authenticating using that specific token (e.g., by sending a link: https://bank.lan/login?SID=12345 ). When the victim logs in, the server elevates the status of SID=12345 to authenticated without changing its value. The attacker then uses the known SID=12345 to access the victim's account.

Cookie Security Attributes & Scope Restrictions

Cookies are the dominant vehicle for maintaining session state in web applications. Servers issue cookies via the Set-Cookie HTTP response header, and client browsers automatically include matching cookies in the Cookie header of subsequent requests directed to matching domains and paths. Set-Cookie: session_id=v9x2K1...; Domain=corp.com; Path=/app; Secure; HttpOnly; SameSite=Strict +-----------------------------------------------------------------------------+

  • | COOKIE SECURITY ATTRIBUTES |
  • +-----------------------------------------------------------------------------+
  • | Attribute | Directive Values | Defensive Security Function |
  • +-----------+------------------+----------------------------------------------+
  • | Secure | (Flag present) | Cookie sent ONLY over TLS/HTTPS connections. |
  • | | | Prevents cleartext sniffing over HTTP. |
  • | HttpOnly | (Flag present) | Blocks client-side JavaScript access |
  • | | | (document.cookie). Mitigates XSS theft. |
  • | SameSite | Strict | Withheld on ALL cross-site requests. |
  • | | Lax | Sent on top-level safe GET navigations; |
  • | | | withheld on cross-site POST/subrequests. |
  • | | None | Sent on all cross-site requests. Requires |
  • | | | 'Secure' flag to be accepted by browsers. |
  • | Domain | .domain.com | Restricts cookie to host and subdomains. |
  • | | (Omitted) | Host-only cookie: restricted solely to host. |
  • | Path | /directory | Limits cookie transmission to target URI. |
  • +-----------------------------------------------------------------------------+
  • Deep-Dive on Cookie Flags

Secure Flag: Instructs the browser that the cookie must only be transmitted over encrypted connections (HTTPS). If a user inadvertently accesses the application over unencrypted HTTP (e.g., typing http://example.com ), the browser will refuse to send the cookie, preventing network eavesdroppers from capturing the plaintext session token.

HttpOnly Flag: Forbids client-side scripts (such as JavaScript) from accessing the cookie through the Document Object Model ( document.cookie ). If an attacker identifies a stored or reflected Cross-Site Scripting (XSS) vulnerability, the presence of HttpOnly prevents their injected payload from stealing the session cookie directly, neutralizing the primary pathway for automated session hijacking.

SameSite Attribute (CSRF Defense): Controls whether cookies are transmitted during cross-site requests (requests initiated from an external third-party domain targeting the application).

SameSite=Strict : The cookie is never sent in cross-site requests under any circumstances—even if the user clicks an ordinary hyperlink from an external email or website. This offers the strongest protection against Cross-Site Request Forgery (CSRF) .

SameSite=Lax : The default setting in modern browsers. The cookie is withheld on cross-site subrequests (such as <img> , <iframe> , or AJAX calls) and state-changing cross-site POST submissions, but is sent when a user follows a standard top-level inbound hyperlink ( <a href="..."> ).

SameSite=None : The cookie is sent on all cross-site requests, including third-party embeds. Browsers require the Secure flag to be set whenever SameSite=None is declared ( SameSite=None; Secure ).

Domain and Path Scope: If the Domain attribute is explicitly set to Domain=example.com , the cookie is accessible by example.com and all of its subdomains (e.g., app.example.com , dev.example.com ). If the Domain attribute is omitted entirely, modern browsers enforce a Host-Only cookie , which is strictly valid only for the exact originating hostname and will not be shared with subdomains.