La lista de revocación de certificados (CRL) es un componente opcional de una implementación de infraestructura de clave pública (PKI) que se ha creado y firmado por una entidad de certificación y que contiene una lista de certificados que dicha autoridad ha emitido y posteriormente revocado. Los certificados pueden ser revocados por un administrador de la entidad de certificación, por ejemplo, si se sabe o se sospecha que un certificado emitido está comprometido.

Ejemplo 1: En el siguiente ejemplo, el comportamiento del servicio se configura para no comprobar la revocación al autenticar un 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>

Los proveedores de servicios que utilizan UsernameToken pueden aceptar contraseñas enviadas en texto sin formato. El envío de contraseñas de texto sin formato a través de un canal no cifrado puede exponer la credencial a los atacantes que pueden examinar el mensaje SOAP.

La siguiente configuración del proveedor de servicios WCF utiliza UsernameToken:

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

El estándar de WS-SecurityPolicy admite siete aserciones a la hora de especificar los tokens auxiliares: SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens, SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens, EndorsingEncryptedSupportingTokens y SignedEndorsingEncryptedSupportingTokens.
Es posible infringir la integridad o la confidencialidad de los tokens que no están firmados o cifrados. Los tokens de respaldo firman la firma del mensaje para evitar manipulaciones de la firma del mensaje.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy permite que se envíen S UsernameToken en mensajes SOAP sin firma ni cifrado:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de la directiva WS-SecurityPolicy no requiere el cifrado de los adjuntos de los mensajes SOAP ya que la etiqueta <EncryptedParts> no contiene una etiqueta <sp:Attachments>:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de la directiva WS-SecurityPolicy no requiere el cifrado de los cuerpos de mensaje SOAP ya que la etiqueta <EncryptedParts> no contiene una etiqueta <sp:Body>:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de la directiva WS-SecurityPolicy no requiere el cifrado de los encabezados de los mensajes SOAP ya que la etiqueta <EncryptedParts> no contiene una etiqueta <sp:Header>:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace simétrico, pero no especifica un token de cifrado:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace asimétrico, pero no especifica un token de cifrado de iniciador:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace asimétrico, pero no especifica un token de firma de iniciador:

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

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace asimétrico, pero no especifica un token de cifrado de destinatario:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace asimétrico, pero no especifica un token de firma de destinatario:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy no requiere que se firmen adjuntos de mensajes SOAP ya que la etiqueta <SignedParts> no contiene una etiqueta <sp:Attachments>:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy no requiere que los cuerpos de los mensajes SOAP estén firmados ya que la etiqueta <SignedParts> no contiene una etiqueta <sp:Body>:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy no requiere que los encabezados de los mensajes SOAP estén firmados ya que la etiqueta <SignedParts> no contiene una etiqueta <sp:Headery>:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza un enlace simétrico, pero no especifica un token de firma:

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

Una marca de tiempo de seguridad indica la actualidad de los datos de seguridad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante podría interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy tiene la etiqueta <IncludeTimestamp> comentada:

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

Cualquier parte de un mensaje que no esté firmada tiene el potencial de que se intercepte y modifique sin el conocimiento del remitente o del receptor. Sin una firma, el receptor no puede verificar criptográficamente que el contenido de un mensaje realmente se originase con el remitente.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy omite la etiqueta <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>

El envío de contraseñas de texto sin formato a través de un canal no cifrado puede exponer la credencial a los atacantes que pueden examinar el mensaje SOAP.

Ejemplo 1: La siguiente entrada de directiva WS-SecurityPolicy utiliza token de nombre de usuario con una contraseña de texto sin formato:

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

Un esquema que no impone una validación de entrada estricta puede permitir la validación de elementos o atributos arbitrarios. Esto abre la puerta a que un atacante suministre un documento malintencionado al sistema.

Ejemplo 1: Imagine que está utilizando los siguientes dos esquemas de validación.

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>

El esquema 1 permite que las etiquetas arbitrarias del espacio de nombres http://itemInfo se validen en él, lo que hace posible que el siguiente XML pase la validación.

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

El XML anterior contiene una etiqueta itemInfo:price que no está definida en el Esquema 2. Como resultado, es posible engañar al consumidor de este documento XML para que fije un precio de 1$ para Shoes.

El elemento <any> significa que se pueden incluir etiquetas arbitrarias en un documento válido. El hecho de permitir contenido arbitrario facilita que los atacantes realicen ataques como la inyección de XML.

Ejemplo 1: Imagine que está utilizando el siguiente esquema de validación.

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

Dado que este esquema usa el elemento <any>, la siguiente documentación XML se considerará válida.

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

Esto es especialmente peligroso cuando se utilizan analizadores SAX, ya que los nodos posteriores sobrescribirán los nodos anteriores.