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?

Não é recomendável que os desenvolvedores criem seus aplicativos usando APIs não documentadas ou ocultas. Não há garantias de que o Google não irá remover ou alterar essas APIs no futuro e, portanto, elas devem ser evitadas. Dessa forma, usar esses métodos ou campos tem um alto risco de violar seu aplicativo.

O código tenta usar o objeto Camera depois que ele já foi liberado. Qualquer referência adicional ao objeto Camera sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de alternância para ativar e desativar a visualização da câmera. Depois que o usuário tocar no botão uma vez, a visualização da câmera será interrompida, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, startPreview() será chamado no objeto Camera anteriormente liberado.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

O código tenta usar o objeto de mídia depois que ele já foi liberado. Qualquer referência adicional a esse objeto de mídia sem a reaquisição do recurso lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir usa um botão de pausa para alternar a reprodução da mídia. Depois que o usuário tocar no botão uma vez, a música ou o vídeo atual será pausado, e o recurso da câmera será liberado. No entanto, se ele tocar no botão novamente, start() será chamado no recurso de mídia anteriormente liberado.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

O código tenta usar o manipulador de banco de dados SQLite do Android depois que ele já foi fechado. Qualquer referência adicional ao manipulador sem o restabelecimento da conexão com o banco de dados lançará uma exceção e poderá fazer com que o aplicativo trave se essa exceção não for detectada.

Exemplo 1: O código a seguir pode ser de um programa que armazena em cache valores de usuário temporariamente na memória, mas que pode chamar flushUpdates() para confirmar as alterações no disco. O método fecha corretamente o manipulador de banco de dados depois de gravar atualizações no banco de dados. No entanto, quando flushUpdates() é chamado novamente, o objeto de banco de dados é referenciado novamente antes da reinicialização.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

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

A minificação melhora os tempos de carregamento de páginas para aplicativos que incluem arquivos JavaScript, reduzindo o tamanho do arquivo. O termo Minificação refere-se ao processo de remover espaços em branco, comentários, pontos-e-vírgulas e chaves desnecessários, de encurtar nomes de variáveis locais e de remover códigos inacessíveis.

Exemplo 1: O código ASPX a seguir inclui a versão não minificada da biblioteca jQuery da Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

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.