A lista de revogação de certificado (CRL) é um componente opcional de uma implantação de infraestrutura de chave pública (PKI) que é criada e assinada por uma autoridade de certificação e contém uma lista de certificados que foram emitidos e, posteriormente, revogados. Os certificados podem ser revogados por um administrador da autoridade de certificação, por exemplo, se um certificado emitido for conhecido ou suspeito de estar comprometido.

Exemplo 1: No exemplo a seguir, o comportamento de um serviço é configurado para não realizar uma verificação de revogação ao autenticar um certificado.

<behavior name="DefaultBehavior" returnUnknownExceptionsAsFaults="false">
  <serviceCredentials>
    <serviceCertificate
      x509FindType="FindBySubjectName"
      findValue="MyCertificate"
      storeLocation="LocalMachine"
      storeName="My"/>
    <clientCertificate>
      <authentication certificateValidationMode="ChainTrust" revocationMode="None"/>
    </clientCertificate>
  </serviceCredentials>
  <metadataPublishing enableGetWsdl="true" enableMetadataExchange="true" enableHelpPage="true"/>
</behavior>

Os provedores de serviços que usam o UsernameToken podem aceitar senhas enviadas em texto simples. O envio de senhas de texto simples por meio de um canal não criptografado pode expor a credencial a invasores que podem detectar a mensagem SOAP.

A seguinte configuração de provedor de serviços WCF usa o UsernameToken:

     ...
     <security mode="Message">
	 <message clientCredentialType="UserName" />
     ...

O padrão WS-SecurityPolicy oferece suporte a sete declarações ao especificar tokens de suporte: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens, EndorsingEncryptedSupportingTokens e SignedEndorsingEncryptedSupportingTokens.
Pode ser possível violar a integridade ou confidencialidade de tokens que não são assinados ou criptografados. Os tokens de endosso assinam a assinatura da mensagem para evitar a violação da assinatura da mensagem.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy permite que UsernameToken seja enviado em mensagens SOAP sem assinatura ou criptografia:

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

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não exige que anexos de mensagens SOAP sejam criptografadas, pois a tag <EncryptedParts> não contém uma tag <sp:Attachments>:

<sp:EncryptedParts>
  <sp:Body/>
</sp:EncryptedParts>

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não requer que os corpos das mensagens SOAP sejam criptografadas, pois a tag <EncryptedParts> não contém uma tag <sp:Body>:

<sp:EncryptedParts>
  <sp:Header .../>
</sp:EncryptedParts>

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não requer não exige que os cabeçalhos das mensagens SOAP sejam criptografadas, pois a tag <EncryptedParts> não contém uma tag <sp:Header>:

<sp:EncryptedParts>
  <sp:Body/>
</sp:EncryptedParts>

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação simétrica, mas não especifica um token de criptografia:

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

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação assimétrica, mas não especifica um token de inicialização de criptografia:

<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>

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação assimétrica, mas não especifica um token de inicialização de assinatura:

<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>

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação assimétrica, mas não especifica um token de criptografia do destinatário:

<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>

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação assimétrica, mas não especifica um token de assinatura do destinatário:

<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>

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não exige que anexos de mensagens SOAP sejam assinados já que a tag <SignedParts> não contém uma tag <sp:Attachments>:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não exige que corpos da mensagem SOAP sejam assinados, já que a tag <SignedParts> não contém uma tag <sp:Body>:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy não exige que os cabeçalhos das mensagens SOAP sejam assinados já que a tag <SignedParts> não contém uma tag <sp:Headery>:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa vinculação simétrica, mas não especifica um token de assinatura:

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

Um carimbo de data/hora de segurança indica a atualização dos dados de segurança de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor pode interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor pode induzir um destinatário a aceitar uma mensagem mal-intencionada.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy tem a tag <IncludeTimestamp> comentada:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem o conhecimento do remetente ou do destinatário. Sem uma assinatura, o receptor não pode verificar criptograficamente se o conteúdo de uma mensagem realmente se originou com o remetente.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy omite a tag <ProtectTokens>:

<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>

O envio de senhas de texto simples por meio de um canal não criptografado pode expor a credencial a invasores que podem detectar a mensagem SOAP.

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy usa o UsernameToken com uma senha de texto simples:

  <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>

Um esquema que não impõe validação de entrada rigorosa pode permitir que elementos ou atributos arbitrários sejam validados em relação a ele. Isso abre a porta para que um invasor forneça um documento mal-intencionado ao sistema.

Exemplo 1: Imagine que você está utilizando os dois esquemas a seguir para validação.

Esquema 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>

Esquema 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>

O esquema 1 permite tags arbitrárias no namespace http://itemInfo para ser validado em relação a ele, permitindo assim que o seguinte XML passe na validação.

<?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>

O XML anterior contém uma tag itemInfo:price que não está definida no Esquema 2. Como resultado, é possível enganar o consumidor desse documento XML e fazer com que ele defina um preço de $1 para Shoes.

O elemento <any> significa que tags arbitrárias podem ser incluídas em um documento válido. Permitir conteúdo arbitrário torna mais fácil para os invasores realizarem ataques como a injeção de XML.

Exemplo 1: Imagine que você está utilizando o esquema a seguir para validação.

<?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>

Uma vez que este esquema usa o elemento <any>, a seguinte documentação XML será considerada válida.

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

Isso é especialmente perigoso ao usar analisadores SAX, pois os nós posteriores sobrescreverão os nós anteriores.