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"
    ...
  }
...
}

Para facilitar el desarrollo y aumentar la productividad, la mayoría de los marcos modernos permiten crear una instancia de un objeto y rellenar ese objeto automáticamente con los parámetros de solicitud HTTP cuyos nombres coincidan con un atributo de la clase `que se va a enlazar. Crear instancias de objetos y rellenar los objetos automáticamente aceleran el desarrollo, pero pueden generar problemas graves si se implementan sin precaución. Cualquier atributo de las clases enlazadas, o clases anidadas, se enlazará automáticamente a los parámetros de solicitud HTTP. Por lo tanto, los usuarios malintencionados podrían asignar un valor a cualquier atributo de las clases enlazadas o anidadas, incluso si no están expuestas al cliente a través de formularios web o contratos API.

Ejemplo 1: Mediante el uso de Spring WebFlow sin configuración adicional, la siguiente acción enlazará los parámetros de solicitud HTTP a cualquier atributo de la clase Booking:

    <view-state id="enterBookingDetails" model="booking">
		<on-render>
			<render fragments="body" />
		</on-render>
        <transition on="proceed" to="reviewBooking">
        </transition>
		<transition on="cancel" to="cancel" bind="false" />
	</view-state>

Donde la clase Booking se define como:

public class Booking implements Serializable {
	private Long id;
	private User user;
	private Hotel hotel;
	private Date checkinDate;
	private Date checkoutDate;
	private String creditCard;
	private String creditCardName;
	private int creditCardExpiryMonth;
	private int creditCardExpiryYear;
	private boolean smoking;
	private int beds;
	private Set<Amenity> amenities;

   // Public Getters and Setters
   ...
}

Los objetos persistentes están enlazados a la base de datos subyacente y se actualizan automáticamente mediante la estructura de persistencia como, por ejemplo, Hibernate o JPA. Al permitir que estos objetos se enlacen dinámicamente a la solicitud por medio de Spring MVC, un usuario podría insertar valores inesperados en la base de datos proporcionando parámetros de solicitud adicionales.
Ejemplo 1: el Order, Customer y Profile son clases Hibernate persistentes.

public class Order {
	String ordered;
	List lineItems;
	Customer cust;
...
}
public class Customer {
	String customerId;
	...
    Profile p;
...
}
public class Profile {
	String profileId;
	String username;
	String password;
	...
}

OrderController es la clase de controlador que administra la solicitud:

@Controller
public class OrderController {
...
	@RequestMapping("/updateOrder")
	public String updateOrder(Order order) {
		...
		session.save(order);
	}
}

Como las clases de comandos se enlazan automáticamente a la solicitud, un atacante puede aprovechar esta vulnerabilidad para actualizar la contraseña de otro usuario agregando los siguientes parámetros a la solicitud: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

Para facilitar el desarrollo y aumentar la productividad, la mayoría de los marcos modernos permiten crear una instancia de un objeto y rellenar ese objeto automáticamente con los parámetros de solicitud HTTP cuyos nombres coincidan con un atributo de la clase `que se va a enlazar. Crear instancias de objetos y rellenar los objetos automáticamente aceleran el desarrollo, pero pueden generar problemas graves si se implementan sin precaución. Cualquier atributo de las clases enlazadas, o clases anidadas, se enlazará automáticamente a los parámetros de solicitud HTTP. Por lo tanto, los usuarios malintencionados podrían asignar un valor a cualquier atributo de las clases enlazadas o anidadas, incluso si no están expuestas al cliente a través de formularios web o contratos API.

En este caso, cuando la anotación [FromBody] se aplica a un parámetro complejo de una acción, y después a cualquier otro atributo vinculante, como [Bind] o [BindNever] aplicados al tipo de parámetro o cualquiera de sus campos se ignoran efectivamente, lo que significa que la mitigación mediante anotaciones vinculantes es imposible.

Ejemplo 1: En una aplicación web ASP.NET Core MVC, cuando la anotación [FromBody] se aplica a un parámetro de una acción, el enlazador de modelos intenta vincular automáticamente todos los parámetros especificados en el cuerpo de la solicitud mediante un formateador de entrada. De forma predeterminada, el enlazador utiliza el formateador de entrada JSON para intentar vincular todos los parámetros posibles que provienen del cuerpo de la solicitud:

[HttpPost]
public ActionResult Create([FromBody] Product p)
{
    return View(p.Name);
}

Tenga en cuenta que cualquier anotación vinculante como [Bind] o [BindNever] aplicada al tipo Product que sigue se ignoran debido a que se utilizan formateadores de entrada cuando la anotación [FromBody] está presente.

public class Product
{
    ...
    public string Name { get; set; }
    public bool IsAdmin { get; set; }
    ...
}

Los marcos modernos permiten a los desarrolladores enlazar automáticamente los parámetros de solicitud HTTP tanto de la consulta de solicitud como del cuerpo en los objetos del modelo para facilitar el desarrollo y aumentar la productividad. Si el enlazador no está configurado correctamente para controlar qué parámetros de solicitud HTTP están enlazados a qué atributos del modelo, un atacante puede abusar del proceso de enlace del modelo y establecer cualquier otro atributo que no deba exponerse al control del usuario. Este enlace es posible incluso si los atributos del modelo no aparecen en los formularios web o los contratos de API.

Ejemplo 1: El siguiente elemento DynaActionForm de Struts 1 define dinámicamente un elemento ActionForm que está enlazado a las solicitudes de los usuarios. En este caso, se utiliza para registrar una cuenta proporcionando el tipo de cuenta y los detalles de un usuario:

<struts-config>
  <form-beans>
       <form-bean name="dynaUserForm"
          type="org.apache.struts.action.DynaActionForm" >
              <form-property name="type" type="java.lang.String" />
              <form-property name="user" type="com.acme.common.User" />
       </form-bean>
       ...

Si el registro se realiza correctamente, los datos del usuario se conservarán en la base de datos. La clase User se define como:

public class User {
  private String name;
  private String lastname;
  private int age;
  private Details details;

  // Public Getters and Setters
  ...
}

Y la clase Details se define como:

public class Details {
  private boolean is_admin;
  private int id;
  private Date login_date;

  // Public Getters and Setters
  ...
}

Dado el escenario del Example 1, un atacante puede ser capaz de explorar la aplicación y detectar si hay un atributo de details en el modelo User. Si este fuera el caso, el atacante puede entonces intentar volver a escribir los valores actuales asignados a sus atributos.
Si un atacante puede encontrar estos atributos internos, y el enlazador del marco no está configurado correctamente para no permitir el enlace de estos atributos, entonces el atacante podría registrar una cuenta de administrador enviando la siguiente solicitud:

type=free&user.name=John&user.lastname=Smith&age=22&details.is_admin=true

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>