Web Application Hardening Assessment

---

name: web-application-hardening-assessment description: | Systematically assess a web application's defensive security posture across input validation, information disclosure, application architecture, and server configuration. Use this skill whenever: evaluating the quality of an application's input handling strategy and whether it correctly applies whitelist vs blacklist vs sanitization approaches; assessing whether boundary validation is implemented at each trust boundary (not only the perimeter); checking whether multistep validation and canonicalization ordering are implemented safely; auditing error handling to determine whether verbose error messages, stack traces, debug output, or database banners are exposed to clients; assessing whether server and service banners are suppressed and whether HTML source comments have been removed; evaluating tiered application architecture for trust-boundary segregation weaknesses, dangerous inter-tier trust relationships, and least-privilege violations; assessing shared hosting or cloud environments for customer isolation deficiencies; auditing application server configuration for default credentials, default content, directory listing exposure, dangerous HTTP methods (WebDAV PUT/DELETE), misconfigured proxy functionality, virtual hosting security gaps, and web application firewall effectiveness; performing a pre-deployment security hardening review; conducting a security architecture review or threat modeling session; reviewing a web application penetration test scope for defensive control gaps. Covers core defense mechanisms (Ch2), information leakage prevention (Ch15), architecture security (Ch17), and application server hardening (Ch18). Maps to CWE-20 (Improper Input Validation), CWE-209 (Information Exposure Through Error Message), CWE-16 (Configuration), CWE-284 (Improper Access Control), CWE-693 (Protection Mechanism Failure). version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/web-application-hackers-handbook/skills/web-application-hardening-assessment metadata: {"openclaw":{"emoji":"📚","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: draft depends-on: [] source-books: - id: web-application-hackers-handbook title: "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" authors: ["Dafydd Stuttard", "Marcus Pinto"] edition: 2 chapters: [2, 15, 17, 18] pages: "53-72, 651-666, 683-703, 705-735" tags: [input-validation, boundary-validation, canonicalization, error-handling, information-disclosure, application-architecture, tiered-architecture, shared-hosting, server-hardening, default-credentials, directory-listing, webdav, web-application-firewall, defense-in-depth, owasp, appsec, cwe-20, cwe-209, cwe-16] execution: tier: 2 mode: hybrid inputs: - type: codebase description: "Application source code — input validation logic, error handlers, framework configuration files — primary for white-box review" - type: document description: "HTTP traffic captures, Burp Suite logs, server configuration files, architecture diagrams — primary for black-box and config audit modes" tools-required: [Read, Grep, Write] tools-optional: [Bash, WebFetch] mcps-required: [] environment: "Run inside a project codebase for white-box review, or with HTTP traffic logs and server config for black-box / configuration assessment. Authorized testing context required." discovery: goal: "Assess the application's defensive posture across four domains — input validation strategy, information disclosure controls, application architecture security, and server hardening — and produce a structured findings report with severity, evidence, and countermeasures" tasks: - "Classify the application's input handling approach for each input type and assess its adequacy" - "Verify boundary validation is performed at each trust boundary, not only the perimeter" - "Test canonicalization ordering — ensure decode-before-validate is applied and no re-encoding after validation" - "Assess error handling for verbose messages, stack traces, debug output, and service banners" - "Audit server configuration for default credentials, default content, directory listings, dangerous methods, proxy misconfiguration, and virtual hosting gaps" - "Evaluate tiered architecture for trust-boundary weaknesses, inter-tier trust abuse risks, and shared hosting isolation" - "Assess web application firewall presence, effectiveness, and bypass susceptibility" - "Document all findings with CWE mapping, severity, and specific countermeasures" audience: roles: ["penetration-tester", "application-security-engineer", "security-minded-developer", "security-architect", "devops-engineer"] experience: "intermediate-to-advanced — assumes familiarity with HTTP, web proxies (Burp Suite or equivalent), server administration basics, and common vulnerability classes" triggers: - "Pre-deployment security hardening review of a web application" - "Penetration test scope includes defense mechanism quality assessment" - "Security architecture review or threat modeling session" - "Post-incident assessment to understand why existing defenses failed" - "Code review targeting input validation and error handling quality" - "Server configuration audit for a newly deployed or migrated application" not_for: - "Testing specific injection vulnerabilities (SQL injection, command injection) — use the injection assessment skill" - "Authentication mechanism testing — use the authentication security assessment skill" - "Access control and session management testing — use the dedicated skills for those domains" - "Client-side attack surface (XSS, CSRF) — use the client-side attack testing skill"

---

Web Application Hardening Assessment

When to Use

You have authorized access to a web application (source code, server configuration, HTTP traffic, or a combination) and need to assess the quality of its defensive security controls — not to find specific exploit payloads, but to evaluate whether the defenses themselves are sound.

This skill applies when:

A security review requires evaluating input validation strategy, not just testing for a specific injection class

Error handling is in scope — determining whether the application leaks internal state, stack traces, database structure, or service versions through error responses

Architecture security is in question — tiered systems, shared hosting, cloud deployments where tier segregation and trust boundaries need assessment

Application server hardening is required — default credentials, default content, directory listings, WebDAV, proxy behavior, virtual hosting, and web application firewall (WAF) effectiveness

The foundational insight from Stuttard and Pinto: Virtually all web applications use the same categories of defense mechanisms. The security difference between applications is not which mechanisms are present, but how well they are implemented. Assessing defensive quality requires understanding what the correct implementation looks like and systematically testing against that standard — not waiting to discover exploitable output.

Four assessment domains, each targeting a different layer of defense: 1. Input handling strategy — Is the correct approach being applied to each input type? Is boundary validation in place at every trust crossing? 2. Information disclosure — What does the application reveal about its internals through errors, headers, comments, and published data? 3. Application architecture security — Do tier boundaries enforce their own controls, or do they trust other tiers blindly? 4. Application server hardening — Has the server platform been hardened against its default configuration weaknesses?

Authorized testing only. This skill is for security professionals with explicit written authorization to assess the target application and server.

---

Context and Input Gathering

Required Context (must have — ask if missing)

Assessment scope (which domains are in scope):

Why: the four domains are largely independent; time-limited engagements may need to prioritize. Input validation and error handling are highest-value in most web app assessments. - Check prompt for: "input validation," "error handling," "server config," "architecture review," "full hardening" - If missing, ask: "Is this a full hardening assessment across all four domains, or are specific areas prioritized? Do you have access to server configuration and application source?"

Testing mode (black-box / white-box / configuration audit):

Why: white-box analysis of source code enables detection of input handling class (whitelist vs blacklist) directly. Black-box testing relies on behavioral response analysis. Server configuration audit requires direct access to httpd.conf, web.xml, IIS config, or equivalent. - Check environment for: source code files, server config files, HTTP traffic captures - If missing, ask: "Do you have access to the application's source code, server configuration files, or only external HTTP access?"

Application tier topology (for architecture domain):

Why: detecting inter-tier trust abuse requires knowing whether components run on separate hosts, whether a shared database exists, and whether shared hosting or cloud infrastructure is involved. - Check environment for: architecture diagrams, deployment scripts, Docker Compose or Kubernetes manifests, hosting provider references - If missing, ask: "Does the application use a multi-tier architecture (separate app server and database)? Is it deployed on shared hosting or a cloud platform?"

Observable Context (gather from environment)

Server response headers:

Look for: Server:, X-Powered-By:, X-AspNet-Version:, X-Generator: headers that reveal technology stack and version; presence of Strict-Transport-Security, Content-Security-Policy, X-Frame-Options If unavailable: note that header analysis requires HTTP access

Error responses:

Look for: HTTP 500 responses, SQL error text in responses, stack trace output, debug console output embedded in HTML If unavailable: proceed with source code analysis of exception handling logic

Configuration files:

Look for: web.config, httpd.conf, nginx.conf, web.xml, php.ini, .htaccess, appsettings.json If unavailable: defer to behavioral testing for configuration weaknesses

Default Assumptions

Assume no server hardening has been performed unless there is direct evidence otherwise — most default server configurations are insecure

Assume all input handling is perimeter-only until boundary validation at each trust crossing is confirmed

Assume verbose error messages are enabled in any environment that has not been explicitly hardened

---

Process

Step 1: Classify the Input Handling Strategy for Each Input Type

ACTION: For each category of user-supplied input the application processes, determine which of the five input handling approaches is being applied. The five approaches are:

1. Reject Known Bad (blacklist) — blocks a list of known-malicious strings or patterns; allows everything else 2. Accept Known Good (whitelist) — defines the set of permitted characters, length, format; blocks everything else 3. Sanitization — transforms input to a safe form (HTML encoding, escaping metacharacters) before use 4. Safe Data Handling — uses inherently safe processing APIs that eliminate the vulnerability class (parameterized queries for SQL, subprocess arrays for OS commands) 5. Semantic Checks — validates business logic authorization (does the submitted account ID belong to the authenticated user?)

WHY: The choice of approach has a direct bearing on how easily the defense can be bypassed. Blacklists are systematically bypassable through encoding, case variation, comment insertion, and null byte injection — a blacklist of SELECT can be bypassed with SeLeCt, SELECT/**/, or %00SELECT. Whitelisting is the strongest defense where feasible. Safe data handling (parameterized queries) eliminates entire vulnerability classes regardless of input content. Understanding which approach is in use for each input type reveals which inputs are inadequately defended and why.

AGENT: EXECUTES — Grep source code for input validation logic, regex patterns, filtering functions, and database query construction. Identify the approach applied to each input category.

For each identified input category, document:

Input type (query parameter, form field, cookie, HTTP header, JSON body field)

Approach currently applied (1-5 from above)

Adequacy assessment: Is this the right approach for this input type?

Bypass risk: If approach 1 (blacklist), it is always rated at least Medium risk without compensating controls

Red flags:

SQL queries built by string concatenation rather than parameterized query APIs

HTML output produced by string interpolation of user data without encoding

File paths constructed by appending user input to a base directory without canonicalization

exec(), system(), shell_exec(), subprocess.call(shell=True) receiving user-controlled values

Any validation logic using replace() on attack strings (stripping, not blocking) rather than rejection

---

Step 2: Verify Boundary Validation at Each Trust Boundary

ACTION: Map all trust boundaries in the application — points where data crosses from one component to another where the receiving component applies different security assumptions. Common trust boundaries: browser-to-server, server-to-database, server-to-SOAP/REST back-end service, server-to-OS command execution, server-to-email sending (SMTP), server-to-LDAP, server-to-cache layer. For each boundary, verify that input validation appropriate to the receiving component's vulnerabilities is applied at that boundary.

WHY: The simple picture of input validation — clean at the perimeter, trust internally — is fundamentally inadequate. Consider a login flow: the application receives the username, validates basic character set (step 1), performs a SQL query to check credentials (step 2), passes account data to a SOAP service to retrieve profile (step 3), renders the account page in HTML (step 4). Each step is a trust boundary. SQL injection defenses must be applied before step 2. XML metacharacter encoding must be applied before step 3. HTML encoding must be applied before step 4. Perimeter validation alone cannot protect all boundaries simultaneously, because conflicting encoding requirements make a single pass impossible: HTML-encoding prevents XSS but does not prevent SQL injection; SQL escaping does not prevent SMTP header injection.

AGENT: EXECUTES — Trace the data flow of key user inputs through the application. For each processing stage, verify that the appropriate validation or encoding for the receiving component is applied immediately before that component receives the data.

Boundary-specific validation requirements to check: | Boundary | Required Defense | |---|---| | Server → SQL database | Parameterized queries or stored procedures (not escaping alone) | | Server → HTML output | HTML entity encoding of all user data in output | | Server → SOAP/XML service | XML metacharacter encoding of user data before XML construction | | Server → OS command | Avoid passing user data to OS commands; if unavoidable, use exec array form, not shell string | | Server → email (SMTP) | Strip or reject CR/LF in any field used in SMTP headers | | Server → file system path | Canonicalize path, validate against allowed base directory, reject traversal sequences | | Server → LDAP | Escape LDAP special characters; prefer LDAP API calls over raw filter construction |

Finding: Any trust boundary where validation appropriate to the receiving component is absent or insufficient constitutes a boundary validation gap.

---

Step 3: Assess Multistep Validation and Canonicalization Ordering

ACTION: Identify all input validation logic that performs multiple sequential operations on user input (for example: strip ipt> (tests non-recursive stripping)

Double URL-encoded characters: %2527 → after first URL decode → %27 → after second → ' (tests validate-before-decode ordering)

Mixed encoding bypasses: %3cscript%3e for