Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry uses symmetric binding, but does not specify an encryption token:

<sp:SymmetricBinding>
    <wsp:Policy>
        <sp:SignatureToken>
            <wsp:Policy>
                ...
            </wsp:Policy>
        </sp:SignatureToken>
        ...
    </wsp:Policy>
</sp:SymmetricBinding>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify an initiator encryption token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify an initiator signature token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify a recipient encryption token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientSignatureToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses asymmetric binding, but does not specify a recipient signature token:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorEncryptionToken>
    <sp:InitiatorSignatureToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:InitiatorSignatureToken>
    <sp:RecipientEncryptionToken>
      <wsp:Policy>
      ...
      </wsp:Policy>
    </sp:RecipientEncryptionToken>
      ...
  </wsp:Policy>
</sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message attachments to be signed since the <SignedParts> tag does not contain a <sp:Attachments> tag:

<sp:SignedParts>
  <sp:Body/>
</sp:SignedParts>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message bodies to be signed since the <SignedParts> tag does not contain a <sp:Body> tag:

<sp:SignedParts>
  <sp:Header .../>
</sp:SignedParts>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry does not require SOAP message headers to be signed since the <SignedParts> tag does not contain a <sp:Headery> tag:

<sp:SignedParts>
  <sp:Body/>
</sp:SignedParts>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry uses symmetric binding, but does not specify a signature token:

<sp:SymmetricBinding>
    <wsp:Policy>
        <sp:EncryptionToken>
            <wsp:Policy>
                ...
            </wsp:Policy>
        </sp:EncryptionToken>
        ...
    </wsp:Policy>
</sp:SymmetricBinding>

A Security timestamp indicates the freshness of a message's security data. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker could intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may trick a recipient into accepting a malicious message.

Example 1: The following WS-SecurityPolicy policy entry has the <IncludeTimestamp> tag commented out:

  <sp:AsymmetricBinding>
    <wsp:Policy>
      ...
      <!--<sp:IncludeTimestamp/>-->
      <sp:ProtectTokens/>
      <sp:OnlySignEntireHeadersAndBody/>
    </wsp:Policy>
  </sp:AsymmetricBinding>

Any part of a message that is not signed has the potential to be intercepted and modified without the knowledge of the sender or the receiver. Without a signature, the receiver cannot cryptographically verify that the contents of a message really originated with the sender.

Example 1: The following WS-SecurityPolicy policy entry omits the <ProtectTokens> tag:

<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:InitiatorToken>
    ...
    </sp:InitiatorToken>
    <sp:RecipientToken>
    ...
    </sp:RecipientToken>
    <sp:AlgorithmSuite>
    ...
    </sp:AlgorithmSuite>
    <sp:Layout>
    ...
    </sp:Layout>
    <sp:IncludeTimestamp/>

    <sp:OnlySignEntireHeadersAndBody/>
  </wsp:Policy>
</sp:AsymmetricBinding>

Sending plain text passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.

Example 1: The following WS-SecurityPolicy policy entry uses the UsernameToken with a plain text password:

  <sp:SupportingTokens>
    <wsp:Policy>
      <sp:UsernameToken
        sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
        <wsp:Policy>
          <sp:WssUsernameToken11/>
        </wsp:Policy>
      </sp:UsernameToken>
    </wsp:Policy>
  </sp:SupportingTokens>

A schema that does not enforce strict input validation can allow arbitrary elements or attributes to be validated against it. This opens the door for an attacker to supply a malicious document to the system.

Example 1: Imagine you are using the following two schemas for validation.

Schema 1:

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"  >
  <xs:element name="cart" >
    <xs:complexType>
      <xs:sequence>
	<xs:element name="itemID" maxOccurs="1" />
	<xs:any namespace="http://itemInfo" processContents="lax" minOccurs="1" maxOccurs="5"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Schema 2:

<?xml version="1.0"?>
<xsd:schema targetNamespace="http://itemInfo" xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
  <xsd:element name="name" type="xsd:string"/>
  <xsd:element name="description" type="xsd:string"/>
</xsd:schema>

Schema 1 permits arbitrary tags in the http://itemInfo namespace to be validated against it, thus allowing the following XML to pass validation.

<?xml version=\"1.0\" ?>
<cart xmlns:itemInfo="http://itemInfo">
  <itemID>123</itemID>
  <itemInfo:name>Shoes</itemInfo:name>
  <itemInfo:description>Black Shoes</itemInfo:description>
  <itemInfo:price>1.00</itemInfo:price>
</cart>

The preceding XML contains an itemInfo:price tag which is not defined in Schema 2. As a result, it might be possible to trick the consumer of this XML document into setting a price of $1 for Shoes.

The <any> element means arbitrary tags can be included in a valid document. Permitting arbitrary content makes it easier for attackers to perform attacks like XML injection.

Example 1: Imagine you are using the following schema for validation.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"  >
  <xs:element name="cart" >
    <xs:complexType>
      <xs:sequence>
	<xs:element name="itemID" maxOccurs="1" />
	<xs:element name="price" maxOccurs="1" />
	<xs:element name="description" maxOccurs="1"/>
	<xs:any minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="description" type="xs:string"/>
  <xs:element name="name" type="xs:string"/>
  <xs:element name="price" type="xs:decimal"/>
  <xs:element name="code" type="xs:string"/>
</xs:schema>

Since this schema uses the <any> element, the following XML documentation will be considered valid.

<?xml version=\"1.0\" ?>
<cart>
  <itemID>123</itemID>
  <price>50.00</price>
  <price>1.0</price>
</cart>

This is especially dangerous when using SAX parsers since later nodes will overwrite previous nodes.

Processing XML documents can be computationally expensive. Attackers may take advantage of schemas that allow unbounded elements by supplying an application with a very large number elements causing the application to exhaust system resources.

The following is an example of a schema that allows unbounded bar elements.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
  <xs:element name="foo" >
    <xs:complexType>
      <xs:sequence>
	<xs:element name="bar" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

A schema that does not restrict element namespaces permits arbitrary elements to be included in a valid document. This makes it easier for attackers to perform attacks like XML injection by including tags that do not conform to the standards imposed on the rest of the document.

The following schema allows unrestricted namespaces.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
 <xs:element name='foo'>
  <xs:complexType>
   <xs:sequence>
     <xs:any namespace='##any' />
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema>

Transmitting account information over an unencrypted channel, hardcoding credential information inside the application code, unencrypted storage of account details in insufficiently protected backup files are some of the potential causes that might enable an attacker to gain access to victim's private information. The attacker can use this information to gain access to sensitive resources or privileged functionality.

The account information can either be supplied directly by the user during the registration or login process, accessed from a database or similar data store by the application or indirectly provided by a partner or other third party. Privacy violation occurs when this data is insecurely written to a console, file system, or a network location.

Unsafe logging of account information is also risky. Security and privacy concerns often seem to compete with each other. From a security perspective, you must record all important operations so that any anomalous activity can be later identified. However, when private data is involved, this practice can in fact create risk.

In addition to the risk of this information being prone to unauthorized access, developers must also take into account potential for misconduct by individuals who do have access to the data.

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

If access restrictions are not implemented correctly, an attacker can modify the file name or extension in a specific manner to bypass them. The attacker can, for instance, change the extension from lower to upper case and bypass restrictions that fails to account for case sensitivity. This can lead to a sensitive information disclosure and the recovery of sensitive data such as application source code, database authentication credentials, etc.

All SSL/TLS certificates issued before December 1, 2017 from the Symantec infrastructure are deprecated and are no longer trusted by major browsers including Chrome, Firefox, Safari, Internet Explorer, and Edge. This includes all certificates issued by Symantec and its affiliated subsidiary CA's: Thawte, GeoTrust, Equifax, Verisign, and RapidSSL.
Symantec CA public key infrastructure was acquired by DigiCert in October 2017. Starting December 1, 2017, DigiCert took over the validation and issuance of all Symantec SSL/TLS certificates. These new and reissued certificates that use DigiCert as the root CA are trusted by all browsers.
Deprecated certificates imply that the certificate fails to protect the privacy and integrity of user data on the SSL/TLS communication channel. Customers who access websites that use deprecated certificates receive a "Your connection is not private" warning to deter them from continuing to the website.

Directory listing vulnerabilities leak a complete index of all of the resources located in that directory. These vulnerabilities can result in exposure of files that should remain hidden, such as data files, backed-up source code, or applications in development. Unrestricted access to files containing sensitive information can aid further attacks against the application.
Directory listing vulnerabilities can be caused by:
1. Poor default configuration

In the absence of a default directory file, server configuration enables directory listing by default. In addition, the following configuration and setup examples might reveal directory contents to attackers:
Example 1: In many default configurations, certain modules installed on the server (e.g. mod_autoindex module for Apache HTTP Server) can enable directory listing to be obtained from the server even if index files exist and server directory listings configuration is disabled.
Example 2: Enabling services like WEBDAV on IIS server might also lead to exposure of directory contents. With the PROPFIND method, it might be possible to browse and list the contents of directories, even if a default directory file (such as "default.htm") exists.
Example 3: In its default configuration, Netscape Enterprise Server has a feature called "Directory Indexing" turned on. When directory listing is enabled, the server returns directory listings to web users.
2. Input Validation
Failure to validate user supplied data can cause directory listing vulnerabilities in servers and applications. Attackers can manipulate filenames and paths in the request URI to gain access to directory contents.
Example 4: JRun: A remote attacker can send a URL request appended with '%3f.jsp' to the server and gain access to the web root directory.
Example 5: BadBlue Webserver: Sending a request with % appended to the path causes the server to disclose the directory contents.
Example 6: Tomcat: Allows attackers to obtain complete directory listings by making a request containing a null byte.
Example 7: WebSTAR: The default installation contains a sample script that attackers can use to gain a directory listing of any directory on the server. Passing an asterisk (*) in the query string and appending it to the target directory path causes the script to disclose directory contents.
3. Encoding
Failure to properly handle requests containing encoded special characters can result in directory listing vulnerabilities
Example 8: Attackers can view the contents of web directories by requesting certain encoded characters. By appending certain characters to a request for a directory, an attacker can "break" the mechanism a server uses to determine whether a request is for a directory or not and thus give a full directory listing.
Example 9: Appending an encoded null-byte to the directory name can reveal directory contents.
4. Traversal vulnerabilities
Failure to validate paths to requested directories can allow attackers to gain access to arbitrary directory contents through traversal attacks.
Example 1: /../examples//WEB-INF/../../../../
5. Access Control error
Exposure of sample or test scripts or administrative interfaces can allow attackers to browse contents of arbitrary directories.