Web Application Hardening Assessment

Scenario: Pre-deployment hardening review of a financial services portal Trigger: "Before we go live next month, we need a security review of the server configuration and input handling across the application." Process: 1. Step 1 (input handling classification): Review database query construction — 3 of 12 query-building functions use string concatenation with user parameters rather than parameterized queries. Classified as Approach 1 (Reject Known Bad) in two cases (blacklisting single-quote) and no validation in the third. Findings: 2 High (blacklist-only SQL), 1 Critical (no validation on admin query). 2. Step 2 (boundary validation): Trace username from login form through: (a) HTML login page rendering — username HTML-encoded before output, compliant; (b) SQL query for credential check — parameterized, compliant; (c) SOAP service call for profile data — username interpolated directly into XML payload, no XML metacharacter encoding, finding: XML injection risk at SOAP boundary. 3. Step 4 (error handling): Trigger a database error by submitting a type-mismatch value. Response contains full stack trace including Oracle JDBC connection string with hostname and credentials: jdbc:oracle:thin:apps/appspassword@db-prod-01.internal:1521/PROD. Critical finding: credential disclosure in error message. 4. Step 6 (server config): Apache Tomcat detected. Access /manager/html — returns 401 with authentication prompt. Test credentials tomcat/tomcat — authentication succeeds. WAR file deployment interface accessible with default credentials. Critical finding. 5. Step 7 (directory listings): 4 of 11 directories return Apache directory indexes. One exposed directory contains backup_2023-11-01.sql.gz — database backup file downloadable without authentication. Output: 2 Critical, 4 High, 3 Medium findings across all four domains.

Scenario: Architecture security review of a multi-tenant SaaS application Trigger: "We host multiple enterprise clients on the same platform. A security consultant flagged concerns about tenant isolation. Can you do a full architecture review?" Process: 1. Step 9 (tiered architecture): Review database connection configuration — a single database account app_user with GRANT ALL PRIVILEGES is used for all operations. All tenants' data in the same schema with tenant_id discrimination in queries. SQL injection in any query can access any tenant's data. Finding: High — insufficient database-level tenant isolation. 2. Step 10 (shared hosting): Review OS account configuration — all tenant application containers run as www-data. Path traversal in any tenant application could read other tenants' uploaded files, which are all accessible to www-data. Finding: High — insufficient OS-level filesystem isolation. 3. Step 11 (WAF): WAF is present (detected via custom cookie X-WAF-Token). Test: submitting ' OR 1=1-- in query string is blocked. Same payload in JSON POST body passes through. Finding: Medium — WAF does not inspect JSON request bodies. 4. Step 2 (boundary validation): Multi-tenant SOAP endpoint receives tenant-supplied data that is interpolated into XML without encoding. One tenant could inject XML to interfere with another tenant's SOAP requests. Output: Architecture recommendations include separate database accounts per tenant with row-level security, per-tenant OS accounts with restricted filesystem access, and WAF configuration update for JSON body inspection.

Scenario: Error handling and information disclosure audit of an e-commerce application Trigger: "We're getting strange error pages appearing on our site during our pen test engagement. Can you review our error handling posture?" Process: 1. Step 4 (error handling): Systematically inject type-mismatch values into each parameter category. Three findings: (a) product ID parameter returns Oracle SQL state and partial query text on invalid input; (b) order search by date returns ASP.NET stack trace revealing .NET version 4.5.2 and full file path; (c) admin user endpoint triggers custom debug message dumping session variables including SessionKey value. 2. Step 5 (header/comment disclosure): Server header reveals Microsoft-IIS/8.5. HTML source of checkout page contains commented-out block: . Finding: test payment card data embedded in production HTML comment. 3. Countermeasures: Configure customErrors mode="On" in web.config with generic error page redirect; suppress Server: header via URLScan/IIS Lockdown; remove all HTML comments from production deployment pipeline. Output: 5 information disclosure findings (1 Critical for session key exposure, 2 High for stack trace + SQL error, 2 Medium for version banners and payment card in comment).