In App Firewall
In NetScaler 11.1
In Citrix ADC
In All products
Product documentation
In App Firewall
In NetScaler 11.1
In Citrix ADC
In All products
NetScaler
13.0 12.1 11.1
View PDF

Web services interoperability check

September 21, 2020
Contributed by: 
C

The Web Services Interoperability (WS-I) check examines both requests and responses for adherence to the WS-I standard, and blocks those requests and responses that do not adhere to this standard. The purpose of the WS-I check is to block requests that might not interact with other XML appropriately. An attacker can use inconsistencies in interoperability to launch an attack on your XML application.

If you use the wizard or the GUI, in the Modify Web Services Interoperability Check dialog box, on the General tab you can enable or disable the Block, Log, Statistics, and Learn actions.

If you use the command-line interface, you can enter the following command to configure the Web Services Interoperability check:

  • set appfw profile <name> -xmlWSIAction [block] ][log] [learn] [stats] [none]

To configure individual Web Services Interoperability rules, you must use the GUI. On the Checks tab of the Modify Web Services Interoperability Check dialog box, select a rule and click Enable or Disable to enable or disable the rule. You can also click Open to open the Web Services Interoperability Detail message box for that rule. The message box displays read-only information about the rule. You cannot modify or make other configuration changes to any of these rules.

The WS-I check uses the rules listed in WS-I Basic Profile 1.0.  WS-I delivers best practices for developing interoperable Web Services solutions.  WS-I checks are performed only on SOAP Messages.

Description of each WSI standard rule is provided below:

Rule Description
BP1201 Message body should be a soap:envelope with namespace.
R1000 When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have element children other than faultcode, faultstring, faultactor and detail.
R1001 When an ENVELOPE is a Fault, the element children of the soap:Fault element MUST be unqualified.
R1003 A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than the namespace of the qualified document element Envelope.
R1004 When an ENVELOPE contains a faultcode element, the content of that element SHOULD be either one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element), or a Qname whose namespace is controlled by the fault’s specifying authority (in that order of preference).
R1005 An ENVELOPE MUST NOT contain soap:encodingStyle attribute on any of the elements whose namespace is the same as the namespace of the qualified document element Envelope.
R1006 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.
R1007 An ENVELOPE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any element that is a grandchild of soap:Body.
R1011 An ENVELOPE MUST NOT have any element children of soap:Envelope following the soap:Body element.
R1012 A MESSAGE MUST be serialized as either UTF-8 or UTF-16.
R1013 An ENVELOPE containing a soap:mustUnderstand attribute MUST only use the lexical forms 0 and 1.
R1014 The children of the soap:Body element in an ENVELOPE MUST be namespace qualified.
R1015 A RECEIVER MUST generate a fault if they encounter an envelope whose document element is not soap:Envelope.
R1031 When an ENVELOPE contains a faultcode element the content of that element SHOULD NOT use of the SOAP 1.1 dot notation to refine the meaning of the fault.
R1032 The soap:Envelope, soap:Header, and soap:Body elements in an ENVELOPE MUST NOT have attributes in the same namespace as that of the qualified document element Envelope
R1033 An ENVELOPE SHOULD NOT contain the namespace declaration: xmlns:xml=http://www.w3.org/XML/1998/namespace.
R1109 The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.
R1111 An INSTANCE SHOULD use a 200 OK HTTP status code on a response message that contains an envelope that is not a fault.
R1126 An INSTANCE MUST return a 500 Internal Server Error HTTP status code if the response envelope is a Fault.
R1132 A HTTP request MESSAGE MUST use the HTTP POST method.
R1140 A MESSAGE SHOULD be sent using HTTP/1.1.
R1141 A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0.
R2113 An ENVELOPE MUST NOT include the soapenc:arrayType attribute.
R2211 An ENVELOPE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of 1 or true on the part accessors.
R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains an envelope. Specifically, the HTTP response entity-body must be empty.
R2729 An ENVELOPE described with an rpc-literal binding that is a response MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the stringResponse.
R2735 An ENVELOPE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace.
R2738 An ENVELOPE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it.
R2740 A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:fault describing each known fault.
R2744 A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description.
Web services interoperability check
September 21, 2020
Contributed by: 
C
September 21, 2020
Contributed by: 
C

In this article

Site feedback | Privacy and legal terms | Cookie preferences | Consent settings
© 1999- Citrix Systems, Inc. All rights reserved.