Por padrão, o ASP.NET valida internamente as assinaturas criptográficas antes de descriptografar cargas úteis, como ViewState, FormsAuth cookies e URLs ScriptResource.axd e passa esses valores para o aplicativo para processamento posterior. No entanto, essa funcionalidade pode ser modificada usando a configuração aspnet:UseLegacyEncryption para desativar a verificação de assinatura criptográfica antes de descriptografar cargas úteis. Isso pode permitir que um cliente mal-intencionado descriptografe, falsifique ou adultere dados criptografados.

Exemplo 1: No exemplo a seguir, aspnet:UseLegacyEncryption está definido como true.

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

Usar uma classe de modelo que possui propriedades obrigatórias (marcadas com o atributo [Required]) e propriedades opcionais (não marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém mais dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

O fato de haver níveis combinados de exigência sem a comunicação explícita de quais parâmetros devem ser associados a modelos pode indicar que existem propriedades de modelo para uso interno, mas que essas propriedades podem ser controladas por um invasor.

O código a seguir define uma possível classe de modelo que tem propriedades com [Required] e propriedades sem [Required]:

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

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

    public Boolean IsAdmin { get; set; }
}

Se qualquer parâmetro opcional puder alterar o comportamento de um aplicativo, talvez um invasor seja capaz de realmente mudar esse comportamento comunicando um parâmetro opcional em uma solicitação.

Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

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

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

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

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

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

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem ser detectada pelo destinatário. Sem uma assinatura, um destinatário não pode verificar criptograficamente se o conteúdo de uma mensagem é autêntica.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar mensagens não assinadas:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem a modificação ser detectada pelo destinatário. Sem uma assinatura, um receptor não pode verificar criptograficamente a integridade ou origem do conteúdo da mensagem.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar carimbos de data/hora não assinados:

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

Um carimbo de data/hora de segurança indica a atualização 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. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

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 poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar mensagens com carimbos de data/hora sem assinatura:

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

Os carimbos de data/hora de segurança indicam a "atualização" da semântica de segurança da mensagem. Portanto, se uma mensagem for interceptada e retransmitida posteriormente, o destinatário pode rejeitar mensagens obsoletas. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

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, pode ser possível interceptar uma mensagem SOAP e modificar o carimbo de data/hora sem o conhecimento do destinatário. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar carimbos de data/hora não assinados:

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

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.

A seguinte configuração do cliente diz ao Axis 2 para aceitar mensagens não assinadas:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem a modificação ser detectada pelo destinatário. Sem uma assinatura, um receptor não pode verificar criptograficamente a origem do conteúdo da mensagem.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar solicitações não assinadas:

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

Um carimbo de data/hora de segurança indica a atualização 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. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

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 poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar carimbos de data/hora sem assinatura:

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

Um carimbo de data/hora de segurança indica a atualização 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. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

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 poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar carimbos de data/hora sem assinatura:

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

O DNSSEC impede a falsificação de DNS fornecendo a capacidade de usar assinaturas digitais para validação de resposta de DNS. O DNSSEC de um Domínio do Cloud DNS não está habilitado.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita o DNSSEC em um Domínio do Cloud DNS definindo state como off no bloco dnssec_config.

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

Para facilitar o desenvolvimento e aumentar a produtividade, a maioria das estruturas modernas permite que um objeto seja automaticamente instanciado e preenchido com os parâmetros de solicitação HTTP cujos nomes correspondem a um atributo da classe a ser vinculada. A instanciação e o preenchimento automáticos de objetos aceleram o desenvolvimento, mas podem levar a sérios problemas se implementados sem cuidado. Qualquer atributo nas classes vinculadas, ou classes aninhadas, será automaticamente vinculado aos parâmetros de solicitação HTTP. Portanto, usuários mal-intencionados poderão atribuir um valor a qualquer atributo em classes vinculadas ou aninhadas, mesmo que não sejam expostos ao cliente por meio de formulários da web ou contratos de API.

Exemplo 1: Ao usar Spring WebFlow sem configuração adicional, a ação a seguir vinculará os parâmetros de solicitação HTTP a qualquer atributo na classe 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>

Onde a classe Booking é definida 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
   ...
}

Objetos persistentes estão vinculados ao banco de dados subjacente e são atualizados automaticamente pela estrutura de persistência, como o Hibernate ou o JPA. Permitir que esses objetos sejam dinamicamente associados à solicitação pelo Spring MVC permitirá que um invasor injete valores inesperados no banco de dados, fornecendo parâmetros de solicitação adicionais.
Exemplo 1: As classes Order, Customer e Profile são classes do Hibernate mantidas como 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 é uma de classe de controlador Spring que lida com a solicitação:

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

Como classes de comandos são automaticamente associadas à solicitação, um invasor pode usar essa vulnerabilidade para atualizar a senha de outro usuário adicionando os seguintes parâmetros de solicitação à solicitação: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

Para facilitar o desenvolvimento e aumentar a produtividade, a maioria das estruturas modernas permite que um objeto seja automaticamente instanciado e preenchido com os parâmetros de solicitação HTTP cujos nomes correspondem a um atributo da classe a ser vinculada. A instanciação e o preenchimento automáticos de objetos aceleram o desenvolvimento, mas podem levar a sérios problemas se implementados sem cuidado. Qualquer atributo nas classes vinculadas, ou classes aninhadas, será automaticamente vinculado aos parâmetros de solicitação HTTP. Portanto, usuários mal-intencionados poderão atribuir um valor a qualquer atributo em classes vinculadas ou aninhadas, mesmo que não sejam expostos ao cliente por meio de formulários da web ou contratos de API.

Nesse caso, quando a anotação [FromBody] é aplicada a um parâmetro complexo de uma ação, então quaisquer outros atributos de associação, como [Bind] ou [BindNever] aplicados ao tipo do parâmetro ou qualquer um de seus campos são ignorados efetivamente, o que significa que a mitigação usando anotações de associação é impossível.

Exemplo 1: Em um aplicativo Web ASP.NET Core MVC, quando a anotação [FromBody] é aplicada a um parâmetro de uma ação, o associador de modelo tenta vincular automaticamente todos os parâmetros especificados no corpo da solicitação usando um Formatador de Entrada. Por padrão, o associador usa o Formatador de Entrada JSON para tentar vincular todos os parâmetros possíveis que vêm do corpo da solicitação:

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

Observe que quaisquer anotações de associação, como[Bind] ou[BindNever], aplicadas ao tipo Product a seguir são ignorados devido ao uso de Formatadores de Entrada quando a anotação [FromBody] está presente.

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

Estruturas modernas permitem que os desenvolvedores vinculem automaticamente os parâmetros de solicitação HTTP da consulta e do corpo da solicitação aos objetos de modelo para facilitar o desenvolvimento e aumentar a produtividade. Se o associador não estiver configurado corretamente para controlar quais parâmetros de solicitação HTTP estão vinculados a quais atributos de modelo, um invasor pode abusar do processo de vinculação de modelo e definir quaisquer outros atributos que não devem ser expostos ao controle do usuário. Essa ligação é possível mesmo se os atributos do modelo não aparecerem nos formulários da web ou nos contratos de API.

Exemplo 1: O seguinte Struts 1 DynaActionForm define dinamicamente um ActionForm que está vinculado às solicitações do usuário. Neste caso, ele é usado para registrar uma conta, fornecendo o tipo de conta e os detalhes de um usuário:

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

Se o registro for bem-sucedido, os dados do usuário serão mantidos no banco de dados. A clase User é definida como:

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

  // Public Getters and Setters
  ...
}

E a classe Details é definida como:

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

  // Public Getters and Setters
  ...
}

Considerando o cenário no Example 1, um invasor pode ser capaz de explorar o aplicativo e descobrir que existe um atributo details no modelo User. Se esse for o caso, o invasor poderá então tentar substituir os valores atuais atribuídos aos seus atributos.
Se um invasor puder descobrir esses atributos internos e o associador da estrutura não estiver configurado corretamente para impedir a vinculação desses atributos, o invasor poderá registrar uma conta de administrador enviando a seguinte solicitação:

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

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>

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