web-app-security-audit（Web 应用程序安全审计）

Web Application Security Audit

Overview

A structured penetration testing methodology based on *The Web Application Hacker's Handbook*. Guides you through 10 sequential phases to systematically identify vulnerabilities in any web application you're building or reviewing.

When to Use

• Before deploying a web application to production
• When adding authentication, payment processing, or user-facing features
• During periodic security reviews
• After integrating third-party services or APIs
• When you suspect a specific vulnerability class but want comprehensive coverage

When NOT to Use

• Against applications you don't own or have authorization to test
• As a replacement for professional penetration testing on critical systems
• For network-level security (this is application-layer focused)

Process

Work through each phase sequentially. At each phase:

1. Ask targeted questions about the specific application
2. Read the relevant chapter summary from cybersecurity/web-application-hackers-handbook/ for detailed guidance
3. Suggest and execute concrete tests (grep patterns in source code, curl commands, Burp Suite steps, automated scripts)
4. Flag findings with severity: CRITICAL / HIGH / MEDIUM / LOW / INFO
5. Summarize findings before moving to the next phase

If the application doesn't have a relevant surface for a phase (e.g., no file uploads), acknowledge and skip with rationale.

digraph audit_phases {
  rankdir=TB;
  node [shape=box, style=rounded];

  p1 [label="Phase 1\nMap the Application"];
  p2 [label="Phase 2\nAnalyze the Application"];
  p3 [label="Phase 3\nClient-Side Controls"];
  p4 [label="Phase 4\nAuthentication"];
  p5 [label="Phase 5\nSession Management"];
  p6 [label="Phase 6\nAccess Controls"];
  p7 [label="Phase 7\nInjection Vulnerabilities"];
  p8 [label="Phase 8\nApplication Logic"];
  p9 [label="Phase 9\nApplication Server"];
  p10 [label="Phase 10\nReview & Report"];
  report [label="Security Audit\nReport", shape=note];

  p1 -> p2 -> p3 -> p4 -> p5 -> p6 -> p7 -> p8 -> p9 -> p10 -> report;
}

Phase 1: Map the Application

Reference: cybersecurity/web-application-hackers-handbook/ch04-mapping-the-application.md

Goal: Discover the full attack surface before testing anything.

Questions to ask:

• What is the application's tech stack? (framework, language, database, hosting)
• What are all the routes/endpoints? (read route files, API definitions, OpenAPI specs)
• Are there admin panels, API docs, or debug endpoints?
• What third-party services are integrated?

Tests to run:

• Enumerate all routes from source code: # Express.js grep -rn "app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js" # Django grep -rn "path\|url(" --include="*.py" urls.py # Rails grep -rn "get\|post\|put\|delete\|patch\|resources\|resource" config/routes.rb # Next.js — check app/ and pages/ directory structure
• Check for exposed files: robots.txt, sitemap.xml, .env, .git/, package.json
• Search for hardcoded secrets in source: grep -rni "password\|secret\|api_key\|token\|private_key" --include="*.ts" --include="*.js" --include="*.py" --include="*.env*"
• Review HTML/JS comments for sensitive information
• Identify all input vectors: URL params, POST bodies, cookies, headers, file uploads, WebSockets

Deliverable: Complete attack surface map — routes, parameters, technologies, entry points.

Phase 2: Analyze the Application

Reference: cybersecurity/web-application-hackers-handbook/ch03-web-application-technologies.md

Goal: Understand what the application does and identify high-risk areas.

Questions to ask:

• What are the core business functions? (user management, payments, data CRUD, search, file handling)
• Which functions handle sensitive data? (PII, financial, credentials)
• Are there multi-step processes? (checkout, registration, approval workflows)
• What user roles exist? What can each role do?

Prioritize testing areas (highest risk first):

1. Authentication and credential handling
2. Payment/financial transaction processing
3. File upload functionality
4. Administrative interfaces
5. API endpoints (often have weaker controls than web UI)
6. Search functionality (frequent injection target)
7. User-to-user features (stored XSS vector)
8. Data export/import (injection, XXE)

Deliverable: Functional map with risk-prioritized areas of interest.

Phase 3: Test Client-Side Controls

Reference: cybersecurity/web-application-hackers-handbook/ch05-bypassing-client-side-controls.md

Goal: Verify the server never trusts client-side validation or state.

Questions to ask:

• Are there hidden form fields the server relies on? (prices, roles, user IDs)
• Is input validation only done client-side? (JavaScript, HTML5 attributes)
• Does the client transmit data that should be server-side state? (cart totals, discount flags, permission levels)

Tests to run:

• Search for hidden fields: grep -rn 'type="hidden"\|type=.hidden.' --include="*.html" --include="*.tsx" --include="*.jsx"
• Search for client-only validation: grep -rn "maxlength\|pattern=\|required\b" --include="*.html" --include="*.tsx" --include="*.jsx"
• Check if server-side validation mirrors client-side: grep -rn "validate\|sanitize\|zod\|yup\|joi\|class-validator" --include="*.ts" --include="*.js" --include="*.py"
• For each form, submit requests with: missing required fields, values exceeding maxlength, values violating patterns, modified hidden fields
• Test price/role/permission manipulation by modifying request bodies

Finding template:

[SEVERITY] Client-Side Control Bypass: [description]
  Affected: [endpoint/parameter]
  Test: [what you did]
  Result: [what happened]
  Impact: [what an attacker could achieve]
  Fix: [server-side validation recommendation]

Phase 4: Test Authentication

Reference: cybersecurity/web-application-hackers-handbook/ch06-attacking-authentication.md

Goal: Verify authentication cannot be bypassed, brute-forced, or abused.

Tests to run:

Username enumeration:

• Compare responses for valid vs invalid usernames on login, registration, and password reset
• Check response body, status codes, timing differences, and response length
• Search for inconsistent error messages: grep -rn "invalid.*username\|user.*not found\|no.*account\|incorrect.*password" --include="*.ts" --include="*.js" --include="*.py"

Brute-force resilience:

• Check for account lockout, rate limiting, CAPTCHA
• Search for rate limiting implementation: grep -rn "rate.limit\|throttle\|brute\|lockout\|max.*attempts" --include="*.ts" --include="*.js" --include="*.py"

Password policy:

• Test minimum length, complexity requirements, common password blocking
• Check password storage: grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2\|sha256\|sha1\|md5\|plaintext" --include="*.ts" --include="*.js" --include="*.py"
• CRITICAL if passwords stored as plaintext, MD5, or SHA1 without salt

Password reset:

• Check token randomness, expiry, single-use enforcement
• Check if reset tokens are in URLs (logged in server logs, browser history)

Multi-factor authentication:

• Can MFA step be skipped by directly requesting authenticated endpoints?
• Can MFA be bypassed by replaying codes or using expired codes?

Remember me:

• Decode the remember-me token (Base64, JWT) — does it contain user info?
• Is it invalidated on password change?

Phase 5: Test Session Management

Reference: cybersecurity/web-application-hackers-handbook/ch07-attacking-session-management.md

Goal: Verify sessions cannot be hijacked, fixated, or predicted.

Tests to run:

Token generation:

• Collect multiple session tokens and check for patterns (sequential, timestamp-based, low entropy)
• Decode tokens (Base64, JWT) — do they contain sensitive data? # For JWTs grep -rn "jwt\|jsonwebtoken\|jose" --include="*.ts" --include="*.js" --include="*.py"

Cookie flags:

• Check every cookie for: Secure, HttpOnly, SameSite, Domain, Path grep -rn "Set-Cookie\|cookie\|setCookie\|httpOnly\|secure\|sameSite" --include="*.ts" --include="*.js" --include="*.py"
• HIGH if session cookie missing HttpOnly (XSS can steal it)
• HIGH if session cookie missing Secure (transmitted over HTTP)
• MEDIUM if session cookie missing SameSite (CSRF vector)

Session lifecycle:

• Does the token change after login? (session fixation if not)
• Is the session invalidated server-side on logout? (not just cookie deletion)
• Is there idle timeout and absolute timeout?

CSRF protection:

• Identify all state-changing operations (POST/PUT/DELETE)
• Check for anti-CSRF tokens: grep -rn "csrf\|xsrf\|_token\|csrfmiddleware" --include="*.ts" --include="*.js" --include="*.py" --include="*.html"
• Can state-changing requests succeed without the CSRF token?

Phase 6: Test Access Controls

Reference: cybersecurity/web-application-hackers-handbook/ch08-attacking-access-controls.md

Goal: Verify users cannot access unauthorized data or functionality.

Questions to ask:

• What user roles exist? (admin, user, moderator, API consumer)
• How is authorization enforced? (middleware, decorators, inline checks)
• Are there resource IDs in URLs or request bodies that could be manipulated?

Tests to run:

IDOR (Insecure Direct Object Reference):

• Find all endpoints with resource IDs: grep -rn "/users/\|/orders/\|/documents/\|/api/.*/:id\|/api/.*/<.*>" --include="*.ts" --include="*.js" --include="*.py"
• As User A, request User B's resources by changing IDs
• CRITICAL if successful

Vertical privilege escalation:

• As a regular user, request admin endpoints directly
• Check if authorization is enforced per-endpoint: grep -rn "isAdmin\|requireAdmin\|role.*admin\|authorize\|permission\|@Roles\|@RequiresRole" --include="*.ts" --include="*.js" --include="*.py"
• Check if any endpoints lack authorization middleware

Horizontal privilege escalation:

• Modify user-identifying parameters (user_id, account_id, email) in requests
• Check if the server validates that the requested resource belongs to the authenticated user

Multi-step process controls:

• For multi-step flows (checkout, approval), test skipping to later steps directly
• Test performing steps out of order

Phase 7: Test for Injection Vulnerabilities

Reference: cybersecurity/web-application-hackers-handbook/ch09-attacking-data-stores.md, ch10-attacking-back-end-components.md, ch12-attacking-users-xss.md

Goal: Verify all input is safely handled across every context.

SQL Injection:

# Find raw query construction (CRITICAL pattern)
grep -rn "query.*+\|execute.*+\|raw.*+\|\\.format.*SELECT\|f\".*SELECT\|f'.*SELECT" --include="*.ts" --include="*.js" --include="*.py"
# Verify parameterized queries are used
grep -rn "prepare\|parameterized\|\$[0-9]\|placeholder\|\?" --include="*.ts" --include="*.js" --include="*.py"

• CRITICAL if string concatenation/interpolation used in SQL queries

XSS (Cross-Site Scripting):

# Find dangerous DOM operations
grep -rn "innerHTML\|outerHTML\|document\.write\|\.html(\|dangerouslySetInnerHTML\|v-html\|\{!! " --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" --include="*.vue" --include="*.blade.php"
# Find eval usage
grep -rn "eval(\|Function(\|setTimeout.*string\|setInterval.*string" --include="*.ts" --include="*.js"

• HIGH for stored XSS, MEDIUM for reflected XSS, MEDIUM for DOM-based XSS

OS Command Injection:

grep -rn "exec(\|execSync\|spawn(\|system(\|popen\|subprocess\|child_process\|shell_exec\|passthru\|backtick" --include="*.ts" --include="*.js" --include="*.py" --include="*.php"

• CRITICAL if user input flows into command execution

Path Traversal:

grep -rn "readFile\|writeFile\|createReadStream\|open(\|path\.join.*req\|path\.resolve.*req\|fs\." --include="*.ts" --include="*.js" --include="*.py"

• Check if user input is used in file paths without sanitization

XXE (XML External Entity):

grep -rn "parseXML\|DOMParser\|SAXParser\|XMLReader\|etree\.parse\|xml2js\|libxml" --include="*.ts" --include="*.js" --include="*.py"

• Check if external entity processing is disabled

SSRF (Server-Side Request Forgery):

grep -rn "fetch(\|axios\|request(\|urllib\|http\.get\|https\.get\|curl\|wget" --include="*.ts" --include="*.js" --include="*.py"

• Check if user-supplied URLs are validated against an allowlist
• CRITICAL if user input flows directly into server-side HTTP requests without validation

Server-Side Template Injection (SSTI):

grep -rn "render_template_string\|Template(\|Jinja2\|nunjucks.*render\|handlebars.*compile\|ejs.*render" --include="*.ts" --include="*.js" --include="*.py"

• Check if user input is embedded in templates before rendering

Phase 8: Test Application Logic

Reference: cybersecurity/web-application-hackers-handbook/ch11-attacking-application-logic.md

Goal: Identify flaws in business logic that automated scanners cannot find.

Questions to ask:

• What assumptions does each function make about user behavior?
• Are there multi-step processes? Can steps be skipped or reordered?
• Are there financial transactions? Can amounts be manipulated (negative values, zero, overflow)?
• Are there referral/reward/coupon systems? Can they be abused?

Tests to run:

Race conditions:

grep -rn "balance\|credits\|quantity\|stock\|inventory\|coupon\|redeem\|transfer\|withdraw" --include="*.ts" --include="*.js" --include="*.py"

• For any check-then-act pattern (check balance → deduct), test concurrent requests
• HIGH if double-spending or double-redemption is possible

Multi-step process abuse:

• Map every multi-step flow (checkout, registration, approval)
• Test: skip steps, repeat steps, go backward, change data between steps, switch user context between steps

Transaction logic:

• Test negative amounts, zero amounts, extremely large amounts
• Test fractional values where integers expected
• Test self-referral, circular referral chains

Input normalization conflicts:

• Test unicode normalization issues (different representations of same character)
• Test case sensitivity conflicts (register as "Admin" when "admin" exists)

Phase 9: Test Application Server

Reference: cybersecurity/web-application-hackers-handbook/ch18-attacking-the-application-server.md

Goal: Verify the server platform itself is hardened.

Tests to run:

Default credentials:

• Check if admin panels exist at common paths: /admin, /wp-admin, /phpmyadmin, /console, /manager
• Test default credentials for any discovered admin interfaces

Dangerous HTTP methods:

curl -X OPTIONS <target-url> -i

• MEDIUM if PUT, DELETE, or TRACE are enabled unnecessarily

Security headers:

curl -s -I <target-url>

Check for:

• Content-Security-Policy — HIGH if missing (XSS mitigation)
• Strict-Transport-Security — HIGH if missing (HTTPS enforcement)
• X-Frame-Options or CSP frame-ancestors — MEDIUM if missing (clickjacking)
• X-Content-Type-Options: nosniff — LOW if missing (MIME sniffing)
• Referrer-Policy — LOW if missing (information leakage)
• Permissions-Policy — INFO if missing
• Server / X-Powered-By — INFO if present (version disclosure)

Debug mode:

grep -rn "DEBUG.*=.*True\|debug.*:.*true\|NODE_ENV.*development\|FLASK_DEBUG\|DJANGO_DEBUG" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" --include="*.yaml" --include="*.yml"

• HIGH if debug mode enabled in production config

Dependency vulnerabilities:

# Node.js
npm audit
# Python
pip-audit  # or safety check
# Ruby
bundle audit

Known CVEs:

• Check framework/library versions against known vulnerabilities
• CRITICAL for RCE CVEs, HIGH for auth bypass CVEs

Phase 10: Review & Report

Reference: cybersecurity/web-application-hackers-handbook/ch15-exploiting-information-disclosure.md, ch21-web-application-hackers-methodology.md

Final checks:

Information disclosure:

grep -rn "console\.log\|print(\|logger\.\(debug\|info\)\|TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py"

• Check for verbose error messages exposing internals
• Check for exposed .git/, .env, source maps, backup files

SSL/TLS:

# If accessible externally
nmap --script ssl-enum-ciphers -p 443 <target>
# Or use testssl.sh

Generate the audit report:

# Security Audit Report: [Application Name]
**Date:** [date]
**Auditor:** [name]
**Scope:** [what was tested]

## Executive Summary
[1-2 paragraph summary of overall security posture and critical findings]

## Findings Summary
| # | Severity | Finding | Phase |
|---|----------|---------|-------|
| 1 | CRITICAL | [title] | [phase] |
| 2 | HIGH     | [title] | [phase] |
| ... | ... | ... | ... |

## Detailed Findings

### Finding 1: [Title]
**Severity:** CRITICAL / HIGH / MEDIUM / LOW / INFO
**Phase:** [which phase found it]
**Affected Component:** [endpoint, file, function]

**Description:**
[What the vulnerability is and why it exists]

**Reproduction Steps:**
1. [Step-by-step to reproduce]

**Impact:**
[What an attacker could achieve — data access, account takeover, RCE, etc.]

**Remediation:**
[Specific, actionable fix with code example if possible]

**Reference:**
[OWASP, CWE, or WAHH chapter reference]

---
[Repeat for each finding]

## Recommendations Priority
1. [Fix critical/high findings immediately]
2. [Fix medium findings before next release]
3. [Fix low/info findings as part of regular maintenance]

## Out of Scope / Not Tested
[What was explicitly excluded and why]

Severity Rating Guide

Common Mistakes