By default, ASP.NET internally validates the cryptographic signatures before decrypting payloads such as ViewState, FormsAuth cookies, and ScriptResource.axd URLs and passes those values to the application for further processing. However, this functionality can be modified using the aspnet:UseLegacyEncryption setting to disable the cryptographic signature verification before decrypting payloads. This may allow a malicious client to decrypt, forge, or otherwise tamper with encrypted data.

Example 1: In the following example, aspnet:UseLegacyEncryption is set to true.

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

Using a model class that has properties that are required (as marked with the [Required] attribute) and properties that are optional (as not marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains more data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

Having mixed requiredness without explicitly communicating which parameters are to be model-bound may indicate that there are model properties for internal use but can be controlled by attacker.

The following code defines a possible model class that has properties that have [Required] and properties that do not have [Required]:

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

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

    public Boolean IsAdmin { get; set; }
}

If any optional parameters can change the behavior of an application, then an attacker may be able to actually change that behavior by communicating an optional parameter in a request.

Using a model class that has non-nullable properties that are required (as marked with the [Required] attribute) can lead to problems if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties.

If a model has a required non-nullable parameter and an attacker does not communicate that required parameter in a request -- that is, the attacker uses an under-posting attack -- then the property will have the default value (usually zero) which will satisfy the [Required] validation attribute. This may produce unexpected application behavior.

The following code defines a possible model class that has a required enum, which is non-nullable:

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

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

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

If a model class has required property and is the type of an optional member of a parent model class, it may be susceptible to under-posting attacks if an attacker communicates a request that contains less data than is expected.

The ASP.NET MVC framework will try to bind request parameters to model properties, including submodels.

If a submodel is optional -- that is, the parent model has a property without the [Required] attribute -- and if an attacker does not communicate that submodel, then the parent property will have a null value and the required fields of the child model will not be asserted by model validation. This is one form of an under-posting attack.

Consider the following the model class definitions:

public class ChildModel
{
    public ChildModel()
    {
    }

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

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

If an attacker does not communicate a value for the ParentModel.Child property, then the ChildModel.RequiredProperty property will have a [Required] which is not asserted. This may produce unexpected and undesirable results.

Any part of a message that is not signed has the potential to be intercepted and modified without being detected by the receiver. Without a signature, a receiver cannot cryptographically verify that the contents of a message are authentic.

The following service provider configuration tells Axis 2 to accept unsigned messages:

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

Any part of a message that is not signed has the potential to be intercepted and modified without the modification being detected by the receiver. Without a signature, a receiver cannot cryptographically verify the integrity or origin of the message contents.

The following service provider configuration tells Axis 2 to send unsigned timestamps:

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

A Security timestamp indicates a message's freshness. 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. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

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

The following service provider configuration tells Axis 2 to accept messages with unsigned timestamps:

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

Security timestamps indicate the "freshness" of message security semantics. So if a message is intercepted an retransmitted at a later time, the receiver can reject stale messages. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

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

The following service provider configuration tells Axis 2 to send unsigned timestamps:

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

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.

The following client configuration tells Axis 2 to accept unsigned messages:

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

Any part of a message that is not signed has the potential to be intercepted and modified without the modification being detected by the receiver. Without a signature, a receiver cannot cryptographically verify the origin of the message contents.

The following client configuration tells Axis 2 to send unsigned requests:

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

A Security timestamp indicates a message's freshness. 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. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

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

The following client configuration tells Axis 2 to accept unsigned timestamps:

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

A Security timestamp indicates a message's freshness. 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. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

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

The following client configuration tells Axis 2 to send unsigned timestamps:

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

DNSSEC prevents DNS spoofing by providing the ability to use digital signatures for DNS response validation. The DNSSEC of a Cloud DNS Domain is not enabled.

Example 1: The following example shows a Terraform configuration that disables DNSSEC on a Cloud DNS Domain by setting state to off in the dnssec_config block.

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

To ease development and increase productivity, most modern frameworks allow an object to be automatically instantiated and populated with the HTTP request parameters whose names match an attribute of the class to be bound. Automatic instantiation and population of objects speeds up development, but can lead to serious problems if implemented without caution. Any attribute in the bound classes, or nested classes, will be automatically bound to the HTTP request parameters. Therefore, malicious users will be able to assign a value to any attribute in bound or nested classes, even if they are not exposed to the client through web forms or API contracts.

Example 1: Using Spring WebFlow with no additional configuration, the following action will bind the HTTP request parameters to any attribute in the Booking class:

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

Where Booking class is defined as:

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

Persistent objects are bound to the underlying database and updated automatically by the persistence framework, such as Hibernate or JPA. Allowing these objects to be dynamically bound to the request by Spring MVC will let an attacker inject unexpected values into the database by providing additional request parameters.
Example 1: The Order, Customer, and Profile are Hibernate persisted classes.

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 is the Spring controller class handling the request:

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

Because command classes are automatically bound to the request, an attacker may use this vulnerability to update another user's password by adding the following request parameters to the request: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

To ease development and increase productivity, most modern frameworks allow an object to be automatically instantiated and populated with the HTTP request parameters whose names match an attribute of the class to be bound. Automatic instantiation and population of objects speeds up development, but can lead to serious problems if implemented without caution. Any attribute in the bound classes, or nested classes, will be automatically bound to the HTTP request parameters. Therefore, malicious users will be able to assign a value to any attribute in bound or nested classes, even if they are not exposed to the client through web forms or API contracts.

In this case, when the [FromBody] annotation is applied to a complex parameter of an action, then any other binding attributes such as [Bind] or [BindNever] applied to the type of the parameter or any of its fields are effectively ignored, which means that mitigation using binding annotations is impossible.

Example 1: In an ASP.NET Core MVC Web Application when the [FromBody] annotation is applied to a parameter of an action, the model binder automatically tries to bind all parameters specified in the body of the request using an Input Formatter. By default, the binder uses the JSON Input Formatter to try and bind all possible parameters that come from the body of the request:

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

Note that any binding annotations such as [Bind] or [BindNever] applied to the Product type that follows are ignored due to Input Formatters being used when the [FromBody] annotation is present.

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

Modern frameworks allow developers to automatically bind HTTP request parameters from both request query and body into model objects for ease of development and increased productivity. If the binder is not correctly configured to control which HTTP request parameters are bound to which model attributes, an attacker may be able to abuse the model binding process and set any other attributes that should not be exposed to user control. This binding is possible even if the model attributes do not appear in the web forms or API contracts.

Example 1: The following Struts 1 DynaActionForm dynamically defines an ActionForm that is bound to user requests. In this case it is used to register an account by providing the account's type and a user's details:

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

If registration is successful, the user data will be persisted in the database. The User class is defined as:

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

  // Public Getters and Setters
  ...
}

And the Details class is defined as:

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

  // Public Getters and Setters
  ...
}

Given the scenario in Example 1, an attacker may be able to explore the application and discover that there is a details attribute in the User model. If this is the case, the attacker may then attempt to overwrite the current values assigned to their attributes.
If an attacker can find out these internal attributes, and the framework binder is not correctly configured in order to disallow binding of these attributes, then the attacker would be able to register an administrator account by sending the following request:

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

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>

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