Back to scan results
What this check probes
The discovery stage inspects advertised SOAP, WSDL, ASMX, and WCF service references plus a bounded set of common read-only metadata locations. Confirmed WSDL documents are reviewed for xsd:any with lax or skipped validation, xsd:anyType inputs, legacy encoded bindings, and unencrypted SOAP service addresses.
When metadata provides a same-origin HTTPS service address, the scanner sends one SOAP 1.1 or SOAP 1.2 envelope containing the unique operation NoSuchOperation40 in the private namespace urn:pciscan:nonexistent:40. That name is never copied from the WSDL and the message contains only a scanner marker.
A successful non-fault SOAP response, reflected marker, or exposed .NET, Java, Axis, JAX-WS, or PHP SOAP stack detail produces a warning for manual validation. A normal SOAP Fault, access denial, method rejection, media-type rejection, or generic server fault is treated as safe handling.
The scanner never invokes a real WSDL operation and never sends a user or record ID, credential, role, price, command, business parameter, array, XML entity, local-file reference, callback, or transaction value. It does not test authenticated, unlinked, private-network, or dynamically registered services. The separate XXE check covers controlled external-entity handling.
Why this matters for PCI DSS
SOAP injection weaknesses can let unexpected XML elements alter operation parameters, bypass validation, confuse method dispatch, expose internal exceptions, or reach downstream SQL, LDAP, file, and command interpreters. Broad schemas and dynamic dispatch make these failures harder to reason about.
PCI DSS secure-development requirements expect applications to validate structured input against a strict contract, prevent injection, authenticate and authorize service operations, limit message sizes, protect payment data in transit, and return errors without implementation detail.
How to fix it
Define narrow request contracts and dispatch only declared operations. Use concrete data-contract members with validation instead of object, XmlElement, anyType, property bags, or reflection-based method selection:
[DataContract]
public sealed class PaymentStatusRequest
{
[DataMember(IsRequired = true)]
public string MerchantReference { get; set; }
}
[OperationContract]
public PaymentStatusResponse GetPaymentStatus(
PaymentStatusRequest request)
{
if (request == null ||
!MerchantReferencePattern.IsMatch(request.MerchantReference))
throw new FaultException("Invalid request.");
return service.GetAuthorizedStatus(
CurrentMerchantId(), request.MerchantReference);
}
Validate every field for type, length, range, format, and allowed values before it reaches a database, directory, file API, template, or process. Authenticate the message or transport and authorize both the operation and referenced object. Never trust SOAPAction, XML element names, or a client-supplied role or account identifier as authorization.
For WCF on .NET Framework 4.7.2 or 4.8, keep exception detail disabled and configure conservative message and reader quotas:
<serviceDebug includeExceptionDetailInFaults="false" />
<basicHttpBinding>
<binding maxReceivedMessageSize="65536">
<readerQuotas maxDepth="32"
maxStringContentLength="16384"
maxArrayLength="4096"
maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</binding>
</basicHttpBinding>
Disable DTD processing and external resolution in every custom XML parser, validate messages against a strict XSD where practical, reject unexpected elements and duplicate values, and avoid legacy SOAP encoding. Require HTTPS; use WS-Security only where message-level signing or encryption is needed and validate timestamps, signatures, audiences, and replay protections.
Return allowlisted SOAP Faults without stack traces, source paths, framework types, SQL text, or internal hostnames. Log operation name, authenticated identity, correlation ID, validation result, and response category while excluding credentials and sensitive authentication or payment data.