10.5 Web Service Protocols: SOAP, REST & XML Messaging

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

10.5 Web Service Protocols: SOAP, REST & XML Messaging

Key Takeaways Explain This Topic AI

SOAP is an XML-based RPC protocol, usually over HTTP POST, described by a WSDL document and often advertised by a ?wsdl query string.

REST uses the native HTTP methods and status codes as its interface and typically exchanges JSON, but may also exchange XML.

A WSDL enumerates every operation, parameter and data type a SOAP service exposes, making it a complete attack-surface map.

XML documents are validated against a DTD or XML Schema, and it is DTD external-entity processing that enables XXE.

SOAP messages carry a mandatory Envelope and Body and an optional Header used for WS-Security, which is the correct place for message-level authentication.

Last updated: September 2026

10.5 Web Service Protocols: SOAP, REST & XML Messaging

Syllabus item G4 lists HTTP, HTTPS and SOAP as the web protocols, together with all HTTP methods, response codes and security-related header fields. Item G5 covers the web mark-up languages, HTML and XML . Section 10.1 handled HTTP and its methods and codes in depth; this section covers the parts G4 and G5 add on top: SOAP web services , the REST style they are usually compared with, and the XML message model that both mark-up and SOAP depend on.

Web services are where two applications talk to each other rather than to a browser, and they are a rich attack surface precisely because they are often less scrutinised than the human-facing web UI.

1. XML: The Mark-up Model (G5)

XML (eXtensible Markup Language) is a self-describing, hierarchical text format. Unlike HTML, whose tags are fixed and describe presentation, XML tags are defined by the author and describe data . <?xml version="1.0" encoding="UTF-8"?>

<order id="4471">
<customer>Acme Ltd</customer>
<items>
<item sku="A-100" qty="3"/>
</items>
</order>

Two validation mechanisms matter for security:

DTD (Document Type Definition) — the legacy grammar. Critically, a DTD can declare entities , including external entities that pull in content from a URI. This single feature is the root of XXE (XML External Entity) injection , covered in 11.4: <!ENTITY xxe SYSTEM "file:///etc/passwd"> makes a parser read a local file into the document.

XML Schema (XSD) — the modern, more expressive grammar. It does not have the entity mechanism and is the safer choice.

The security-relevant XML concepts are: well-formedness (correct nesting and syntax) versus validity (conformance to a DTD/XSD); namespaces ( xmlns ), which qualify element names; and the fact that entity expansion can be abused for denial of service (the "billion laughs" attack) as well as for file disclosure. Because so many formats are XML underneath — SOAP, SAML, SVG, DOCX/XLSX, RSS, configuration files — XML parser hardening is a cross-cutting concern.

2. SOAP Web Services (G4)

SOAP (Simple Object Access Protocol) is an XML-based protocol for calling remote operations — effectively RPC over XML , almost always transported as an HTTP POST (though SOAP is transport-independent and can run over SMTP or message queues).

A SOAP message has a fixed structure: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<getBalance>
<accountId>4471</accountId>
</getBalance>
</soap:Body>
</soap:Envelope>

Envelope — mandatory root element identifying the message as SOAP.

Header — optional; carries metadata, most importantly WS-Security (message-level authentication, signing and encryption of individual elements).

Body — mandatory; carries the actual operation call and its parameters, or a <soap:Fault> on error.

WSDL: The Attack-Surface Map

A SOAP service is described by a WSDL (Web Services Description Language) document — itself XML — that enumerates every operation the service exposes, every parameter, its data type, and the endpoint URL . WSDLs are frequently retrievable by appending a query string: https://api.example.com/AccountService?wsdl

https://api.example.com/AccountService?WSDL

For an assessor a WSDL is a gift: it is a complete, machine-readable inventory of the service's functions. Tools like SoapUI, Burp's WSDL support, and wsdler parse it and generate template requests for every operation, so testing can proceed function by function. Even undocumented or "internal" operations appear in the WSDL, which is exactly why leaving it publicly retrievable is a finding in its own right.

SOAP-Specific Risks

XXE — SOAP bodies are XML, so any endpoint that parses them with external-entity processing enabled is XXE-vulnerable (11.4).

SOAP injection — breaking out of a parameter to inject extra XML elements, altering the logic of the call (analogous to SQL injection into a query).

Weak or absent WS-Security — authentication placed only at the transport layer (a single TLS session) rather than per message, or username tokens sent in cleartext within the header.

XML signature wrapping — moving signed elements within the document so that a signature validates while the processed content differs.

Verbose <soap:Fault> messages leaking stack traces and internal detail (see 11.5).

3. REST for Contrast

Most modern services are REST (REpresentational State Transfer) rather than SOAP, and the syllabus's HTTP-method and status-code knowledge (G4) maps directly onto REST.

SOAP REST
Interface Operations named inside the XML body HTTP method + URL path ( GET /accounts/4471 )

Payload Always XML (the SOAP Envelope) Usually JSON; can be XML, form data, etc.

Description WSDL OpenAPI/Swagger (when published)
Verb semantics Everything is POST GET reads, POST creates, PUT/PATCH updates, DELETE removes
State Can be stateful (WS-* extensions) Stateless by principle
Security metadata WS-Security in the SOAP Header Bearer tokens / OAuth in HTTP headers

REST's reliance on HTTP verbs makes correct method handling a security matter: a DELETE reachable without authorisation, or a state-changing action wrongly exposed on GET (which enables CSRF and is cached/logged), are common findings. Section 11.4 covers API-specific flaws such as broken object-level authorisation.

Discovery of Web Services # SOAP
GET /service?wsdl # retrieve the WSDL
POST /service (Content-Type: text/xml, SOAPAction: "...") # invoke an operation

# REST
GET /openapi.json /swagger.json /api-docs # retrieve the API description
# then enumerate documented and undocumented endpoints and methods

Content discovery (section 10.3) is how undocumented service endpoints are found; the WSDL or OpenAPI document is how documented ones are mapped exhaustively.

4. Testing Web Services: The Approach

Locate the service description. Try ?wsdl / ?WSDL for SOAP and the common OpenAPI paths for REST; fall back to content discovery and traffic capture.

Enumerate every operation/endpoint from the description, including internal-sounding ones.

Test each operation's inputs for injection (SQLi, XXE, command injection, SOAP/XPath injection), because a web service parameter reaches the same back ends as a web form.

Test authentication and authorisation per operation — services routinely enforce access control on the UI but not on the underlying operation, so calling the operation directly bypasses the UI's checks.

Inspect error handling — <soap:Fault> and REST error bodies frequently leak stack traces, framework versions and internal paths (11.5).

Check the transport and message security — TLS configuration, and whether WS-Security or token validation is actually enforced.

The recurring theme is that a web service is the application without the browser in the way . Every server-side vulnerability the web UI could expose, the service can expose more directly, and often with weaker controls because developers assume only trusted systems will call it.