De forma predeterminada, ASP.NET valida internamente las firmas criptográficas antes de descifrar las cargas útiles, como las direcciones URL ViewState ,FormsAuth cookies y ScriptResource.axd y pasa esos valores a la aplicación para procesarlos posteriormente. Sin embargo, esta funcionalidad se puede modificar utilizando el parámetro aspnet:UseLegacyEncryption para deshabilitar la comprobación de la firma criptográfica antes de descifrar las cargas útiles. Esta alteración puede permitir que un cliente malintencionado descifre, falsifique o altere de otro modo los datos cifrados.

Ejemplo 1: en el siguiente ejemplo, aspnet:UseLegacyEncryption está definido como true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

El uso de una clase de modelo que tiene propiedades requeridas (marcadas con el atributo [Required]) y propiedades opcionales (no marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene más datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

El hecho de tener requisitos mixtos sin comunicar explícitamente qué parámetros se van a enlazar con modelos puede indicar que hay propiedades de modelos para el uso interno, pero pueden estar controlados por un usuario malintencionado.

El siguiente código define una posible clase de modelos que tiene propiedades con [Required] y propiedades sin [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Si algún parámetro opcional puede cambiar el comportamiento de una aplicación, un usuario malintencionado podría cambiar ese comportamiento comunicando un parámetro opcional en una solicitud.

El uso de una clase de modelos con propiedades requeridas que no admiten valores NULL (marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene menos datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

Si un modelo tiene un parámetro requerido que no admite valores NULL y un usuario malintencionado no comunica ese parámetro requerido en una solicitud, es decir, el usuario malintencionado usa un ataque con cantidad reducida de operaciones POST, la propiedad tendrá el valor predeterminado (normalmente cero), que cumplirá con el atributo de validación [Required]. Esto podría producir un comportamiento inesperado de la aplicación.

El código siguiente define una posible clase de modelos que tiene una enumeración requerida que no admite valores NULL:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Si un clase de modelos tiene una propiedad requerida y el tipo de un miembro opcional de una clase de modelos principal, puede ser susceptible a ataques con cantidad reducida de operaciones POST si un usuario malintencionado comunica una solicitud que contiene menos de los que se esperan.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo, incluidos los submodelos.

Si un submodelo es opcional, es decir, el modelo principal tiene una propiedad sin el atributo [Required], y si un usuario malintencionado no comunica ese submodelo, la propiedad principal tendrá un valor null y los campos requeridos del modelo secundario no estarán confirmados por la validación del modelo. Esta es una forma de ataque con cantidad reducida de operaciones POST.

Tenga en cuenta las siguientes definiciones de clases de modelos:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Si un usuario malintencionado no comunica un valor para la propiedad ParentModel.Child, la propiedad ChildModel.RequiredProperty tendrá un [Required] no confirmado. Esto puede producir resultados no esperados y no deseados.

Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor lo detecte. Sin una firma, un receptor no puede verificar criptográficamente que el contenido de un mensaje es auténtico.

La siguiente configuración del proveedor de servicios indica a Axis 2 que acepte mensajes sin firmar:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor detecte la modificación. Sin una firma, un receptor no puede verificar criptográficamente la integridad o el origen del contenido del mensaje.

La siguiente configuración del proveedor de servicios indica a Axis 2 que envíe marcas de tiempo sin firmar:

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

Una marca de tiempo de seguridad indica la actualidad 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. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede 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.

La siguiente configuración del proveedor de servicios indica a Axis 2 que acepte mensajes con marcas de tiempo sin firmar:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

Las marcas de tiempo de seguridad indican la "actualidad" de la semántica de seguridad de los mensajes. De modo que, si un mensaje es interceptado y retransmitido en un momento posterior, el receptor puede rechazar los mensajes obsoletos. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

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

La siguiente configuración del proveedor de servicios indica a Axis 2 que envíe marcas de tiempo sin firmar:

<service>
        ...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

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.

La siguiente configuración del cliente indica a Axis 2 que acepte los mensajes sin firmar:

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor detecte la modificación. Sin una firma, un receptor no puede verificar criptográficamente el origen del contenido del mensaje.

La siguiente configuración del cliente indica a Axis 2 que envíe solicitudes sin firmar:

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

Una marca de tiempo de seguridad indica la actualidad 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. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede 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.

La siguiente configuración del cliente indica a Axis 2 que acepte marcas de tiempo sin firmar:

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

Una marca de tiempo de seguridad indica la actualidad 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. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede 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.

La siguiente configuración del cliente indica a Axis 2 que envíe marcas de tiempo sin firmar:

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

DNSSEC evita la falsificación de DNS al proporcionar la capacidad de usar firmas digitales para la validación de respuestas de DNS. La DNSSEC de un dominio DNS en la nube no está habilitada.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que deshabilita la DNSSEC en un dominio DNS en la nube configurando state en off en el bloque dnssec_config.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    state = "off"
    ...
  }
...
}

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>

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

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 tiene la etiqueta <MessageAge> comentada.

<wsp:Policy
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:wssp="http://www.bea.com/wls90/security/policy"
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
  >
...
<!--   <wssp:MessageAge/> -->

</wsp:Policy>

WS-Security es una mejora de SOAP que proporciona integridad y confidencialidad de los mensajes de un extremo a otro, independientemente del protocolo de transporte. Cuando no se utiliza WS-Security, la integridad y confidencialidad de los mensajes dependen de la seguridad del transporte. Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. WS-Security elimina la dependencia de la seguridad del transporte y la sitúa en el mensaje.

La ausencia de una etiqueta <securityRequestConsumerServiceConfig> en el archivo de extensión del descriptor de implementación del servidor IBM WebSphere WS-Security indica que la seguridad de los mensajes entrantes no está habilitada.

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.