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

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>

Um carimbo de data/hora de segurança indica a atualização dos dados de segurança 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.

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

Exemplo 1: A seguinte entrada da política WS-SecurityPolicy tem a tag <IncludeTimestamp> comentada:

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

Um carimbo de data/hora de segurança indica a atualização dos dados de segurança 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.

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

Exemplo 1: A seguinte entrada da política tem a tag <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>

O WS-Security é um aprimoramento do SOAP que fornece integridade e confidencialidade da mensagem de ponta a ponta, independentemente do protocolo de transporte. Quando o WS-Security não é usado, a mensagem conta com a segurança do transporte para integridade e confidencialidade. Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O WS-Security elimina a dependência de segurança do transporte e a coloca na mensagem.

A ausência de uma tag <securityRequestConsumerServiceConfig> no arquivo de extensão do descritor de implementação do servidor IBM WebSphere WS-Security indica que a segurança da mensagem de entrada não está ativada.

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.