Os valores de atributos para componentes do Oracle ADF Faces podem ser definidos normalmente apenas no servidor. No entanto, vários componentes permitem que o desenvolvedor defina uma lista de atributos que podem ser definidos no cliente. O atributo unsecure desses componentes pode especificar uma lista como essa.

Atualmente, o único atributo que pode aparecer dentro do atributo unsecure é disabled e permite que o cliente defina quais componentes estão habilitados e quais não estão. Nunca é uma boa ideia deixar que o cliente controle os valores de atributos que só devem ser configuráveis no servidor.

Exemplo 1: O código a seguir demonstra um componente inputText que coleta informações de senha do usuário e usa o atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Os cookies são estritamente um mecanismo HTTP, de acordo com a RFC 2109. Não deve haver expectativa razoável de que eles trabalhem para protocolos que não sejam HTTP, incluindo file://. Não está claro qual deve ser seu comportamento e quais regras de compartimentalização de segurança devem ser aplicadas. Por exemplo, os arquivos HTML baixados para o disco local da Internet compartilham os mesmos cookies que qualquer código HTML instalado localmente?

Os aplicativos Android podem ser configurados para produzir binários de depuração. Esses binários fornecem mensagens de depuração detalhadas e não devem ser usados em ambientes de produção. O atributo debuggable da tag <application> define se os binários compilados devem incluir informações de depuração.

O uso de binários de depuração faz com que um aplicativo forneça ao usuário o máximo de informações possível sobre si mesmo. Os binários de depuração devem ser usados em um ambiente de desenvolvimento ou teste e podem representar um risco de segurança se forem implantados em produção. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Por padrão, servidores ASP.NET armazenam na memória o objeto HttpSessionState, seus atributos e quaisquer objetos aos quais eles fazem referência. Esse modelo limita o estado da sessão ativa que pode ser acomodado pela memória do sistema de uma única máquina. Para ampliar a capacidade além dessas limitações, os servidores são frequentemente configurados para informações de estado de sessão persistentes, o que expande a capacidade e também permite a replicação através de várias máquinas a fim de melhorar o desempenho global. Para persistir o estado de sua sessão, o servidor deve serializar o objeto HttpSessionState, o que requer que todos os objetos nele armazenados sejam serializáveis.

Para que a sessão seja serializada corretamente, todos os objetos que o aplicativo armazena como atributos de sessão devem declarar o atributo [Serializable]. Além disso, se o objeto exigir métodos de serialização personalizados, ele também deverá implementar a interface ISerializable.

Exemplo 1: A classe a seguir se acrescenta à sessão, mas, como não é serializável, a sessão não pode ser serializada corretamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseCookiePolicy() adiciona o middleware de política de cookie ao pipeline de middleware, permitindo políticas de cookie personalizadas. Quando especificado na ordem errada, como mostrado, qualquer política de cookie indicada pelo programador será ignorada.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpsRedirection() adiciona o middleware de redirecionamento HTTPS ao pipeline de middleware, que permite o redirecionamento de solicitações HTTP não seguras para uma solicitação HTTPS segura. Quando especificado na ordem errada, conforme mostrado, nenhum redirecionamento HTTPS significativo ocorrerá antes de processar a solicitação por meio do middleware listado antes do redirecionamento. Isso permitirá que as solicitações HTTP sejam processadas pelo aplicativo antes de serem redirecionadas para a conexão HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpLogging() adiciona middleware de registro em log HTTP ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseHttpLogging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Exemplo 2: O método UseWC3Logging() adiciona o middleware de registro em log do W3C ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseWC3Logging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

Definir o modo de validação do certificado como None desativa todo o processo de validação do certificado, o que expõe a aplicação a ataques Man-in-the-Middle. Esse modo nunca deve ser usado em ambientes de produção.

Os cookies são frequentemente usados para armazenar informações importantes sobre os usuários, como informações pessoais, tokens de autenticação e um histórico de suas atividades. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de proteger o conteúdo do cookie e verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Os aplicativos ASP .NET podem ser configurados para produzir binários de depuração. Esses binários fornecem mensagens de depuração detalhadas e não devem ser usados em ambientes de produção. O atributo debug da tag <compilation> define se os binários compilados devem incluir informações de depuração.

O uso de binários de depuração faz com que um aplicativo forneça ao usuário o máximo de informações possível sobre si mesmo. Os binários de depuração devem ser usados em um ambiente de desenvolvimento ou teste e podem representar um risco de segurança se forem implantados em produção. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Quanto mais tempo uma sessão fica aberta, maior a janela de oportunidade que um invasor tem para comprometer contas de usuário. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de aplicar força bruta à senha de um usuário, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão de um navegador aberto. Tempos limites de autenticação mais longos também podem impedir que a memória seja liberada e, eventualmente, resultar em uma denial of service se um número suficientemente grande de sessões for criado.

Exemplo 1: O exemplo a seguir mostra a ASP.NET MVC configurada com um tempo limite de autenticação de uma hora.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

Se o atributo de tempo limite não for especificado, o tempo limite de autenticação será de 30 minutos.

Os programas podem ser configurados para validar certificados X.509 de uma das três maneiras. Por padrão, os certificados são validados por meio de sua cadeia de confiança de volta para uma autoridade raiz confiável. Esta configuração é conhecida como ChainTrust e oferece o nível máximo de garantia de que o certificado é válido. Por padrão, todos os certificados são validados usando o ChainTrust .

Para usar um certificado que não foi emitido por uma autoridade raiz confiável, um programa pode ser configurado para confiar em certificados emitidos por seus pares, definindo PeerTrust ou PeerOrChainTrust . Essas configurações não devem ser usadas em ambientes de produção porque reduzem significativamente o nível de segurança concedido pelos certificados.

Os cookies são frequentemente usados para armazenar informações importantes sobre os usuários, como informações pessoais, tokens de autenticação e um histórico de suas atividades. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de proteger o conteúdo do cookie e verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Se o atributo cacheRolesInCookie do elemento configuration/system.web/authentication/forms em web.config está configurado como true, as funções de cada usuário são armazenadas em cache em um cookie. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Os serviços da web ASP.NET facilitam o desenvolvimento de clientes de serviços da web, gerando automaticamente a documentação que descreve como se comunicar com o serviço da web.

Os serviços da web que têm o protocolo de documentação ativado geram uma página formatada em HTML quando uma solicitação do navegador é recebida.

Esta página formatada em HTML descreve as seguintes informações:
1. As operações que são suportadas
2. Os parâmetros que cada operação aceita
3. O tipo de dado que deve ser passado nesses parâmetros

O protocolo de documentação também gera um arquivo WSDL (Web Services Description Language) formatado em XML. Este arquivo foi projetado para permitir que os aplicativos entendam como estruturar as solicitações para o serviço da web. Essas informações podem ser muito úteis para desenvolvedores, especialmente desenvolvedores que criam clientes para serviços da web públicos. No entanto, revelar informações detalhadas sobre a funcionalidade de serviços da web privados aumenta o risco de que o serviço da web seja usado indevidamente por um invasor mal-intencionado. O protocolo de documentação sempre descreve todas as funções e parâmetros de um serviço da web - mesmo se apenas um subconjunto dessas funções se destina a ser acessível publicamente.

Os aplicativos ASP .NET devem ser configurados para usar páginas de erro personalizadas em vez da página padrão da estrutura. A página de erro padrão fornece informações detalhadas sobre o erro ocorrido e não deve ser usada em ambientes de produção. O atributo mode da tag <customErrors> define se páginas de erro personalizadas ou padrão são usadas.

Os invasores podem aproveitar as informações adicionais fornecidas por uma página de erro padrão para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

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

Os aplicativos ASP.NET podem armazenar pares de nome de usuário e senha em elementos <credentials> no arquivo web.config de um aplicativo ASP.NET, que suporta texto simples e formatos de senha MD5 e SHA1.

As senhas armazenadas em texto simples ou usando um algoritmo de criptografia fraco são acessíveis a qualquer pessoa com acesso aos arquivos de configuração do aplicativo. Isso pode incluir a máquina onde o aplicativo está hospedado ou o repositório de código-fonte onde o aplicativo reside.

Exemplo 1: A seguinte entrada web.config armazena incorretamente suas senhas em texto simples.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

O ASP.NET oferece suporte a senhas de credenciais armazenadas em três formatos, especificados pelo atributo passwordFormat do elemento configuration/system.web/authentication/forms/credentials. Os valores possíveis para este atributo são:

Clear - indica que a senha está armazenada em texto simples (menos seguro)
MD5 - indica que o hash MD5 da senha está armazenado
SHA1 - indica que o hash SHA1 da senha está armazenado (mais seguro)

Embora um hash MD5 seja mais seguro do que texto simples, os pesquisadores descobriram ataques de força bruta contra o algoritmo de hash MD5. No momento, um hash SHA1 ainda fornece proteção razoável contra esses ataques.

Entradas não verificadas são a principal causa de vulnerabilidades em aplicativos ASP.NET. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control e SQL injection.

Para evitar esses ataques, use a estrutura de validação ASP.NET para verificar todas as entradas do programa antes que elas sejam processadas pelo aplicativo.

Exemplos de uso da estrutura de validação incluem verificações para garantir que:

- Campos de número de telefone contenham somente caracteres válidos em números de telefone
- Valores boolianos sejam somente "T" ou "F"
- Cadeias de forma livre tenham um comprimento e uma composição razoáveis

Se o atributo cacheRolesInCookie do elemento configuration/system.web/authentication/forms em web.config está configurado como true, as funções de cada usuário são armazenadas em cache em um cookie. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.