A falta de registros de auditoria limita a capacidade de detectar e responder a incidentes relacionados à segurança e impede a investigação forense.

As definições de configuração que prejudicam os recursos de registro incluem, mas não estão limitadas a:
- desativar deliberadamente o log de auditoria
- isentar o log de ações de usuários, grupos ou processos específicos
- proteger inadequadamente a integridade do log
- não habilitar o log de auditoria opcional
- reduzir a taxa de amostragem de log

A configuração do Terraform configura uma sub-rede de Máquina Virtual sem especificar opções de registro em log. Esses logs contêm dados valiosos para monitoramento de rede, perícia, análise de segurança em tempo real e otimização de despesas.

A má gestão de permissões aumenta o risco de acesso não autorizado ou modificação de dados e prejudica a disponibilidade do serviço.

Uma conta de serviço é uma conta do Google especial usada por um aplicativo ou uma VM em vez de uma pessoa, que usa permissões confidenciais para executar processos automatizados ou fazer solicitações de API em nome de usuários finais. Ela deve ser cuidadosamente gerenciada, controlada e auditada, para que possa ser confiável. A atribuição de uma função de conta de serviço a um usuário do IAM, que normalmente representa uma pessoa, enfraquece o controle de segurança.

A falha em bloquear o tráfego de rede indesejado expande a superfície de ataque de um serviço de nuvem. Os serviços abertos à interação com o público estão sujeitos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

As chaves de criptografia gerenciadas pelo cliente (CMEK) não estão habilitadas para dados em repouso.

Por padrão, o Google Cloud usa Chaves de Criptografia de Dados (DEK) geradas aleatoriamente para criptografar dados em repouso. O recurso CMEK permite que as organizações usem chaves criptográficas de sua escolha para criptografar a DEK. Isso dá às organizações melhor controle e registro de processos de criptografia.

Como tal, a CMEK geralmente faz parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves
- Módulo de segurança de hardware inviolável

As chaves de criptografia gerenciadas pelo cliente (CMEK) não estão habilitadas para dados em repouso.

Por padrão, o Google Cloud usa Chaves de Criptografia de Dados (DEK) geradas aleatoriamente para criptografar dados em repouso. O recurso CMEK permite que as organizações usem chaves criptográficas de sua escolha para criptografar a DEK. Isso dá às organizações melhor controle e registro de processos de criptografia.

Como tal, a CMEK geralmente faz parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves
- Módulo de segurança de hardware inviolável

Um mapa de URL é um conjunto de regras para rotear solicitações HTTP(S) de entrada para serviços de back-end específicos. Por padrão, um mapa de URL aceita conexões não criptografadas e não seguras. Essas conexões expõem os dados a acesso não autorizado, possível roubo e adulteração.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que define um mapa de URL que permite que os clientes usem HTTP para comunicação definindo https_redirect como false.

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

O DNSSEC impede a falsificação de DNS fornecendo a capacidade de usar assinaturas digitais para validação de resposta de DNS. No entanto, qualquer algoritmo de assinatura DNSSEC que use SHA-1 está suscetível a um risco cada vez maior de ataque. O SHA-1 não é mais considerado um algoritmo de hash seguro quando usado com assinaturas digitais.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que habilita o DNSSEC com o algoritmo de assinatura não seguro rsasha1.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

O GKE oferece suporte a dois modos de rede de cluster: baseado em rotas e nativo de VPC. Os clusters nativos de VPC usam intervalos de endereços IP de alias para rotear o tráfego de um pod em um nó para outro pod. Isso permite políticas precisas baseadas em IP e regras de firewall para pods. Em contraste, um nó inteiro é o melhor nível de granularidade de controle em clusters baseados em rotas.

Exemplo 1: O exemplo de configuração do Terraform a seguir não habilita um cluster nativo de VPC definindo networking_mode como ROUTES.

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

X-XSS-Protection é um cabeçalho HTTP introduzido pela Microsoft e, desde então, adotado por outros navegadores. Ele se destinava a ajudar a impedir que ataques de Cross-Site Scripting sejam bem sucedidos, mas, inadvertidamente, levou a uma vulnerabilidade que tornava vulneráveis sites seguros[1]. Por isso, isso não deve ser utilizado em versões mais antigas do Internet Explorer e deve ser desabilitado mediante a definição do cabeçalho como 0.

Exemplo 1: O seguinte configura incorretamente o middleware Helmet em um aplicativo Express para ativar isso em todas as versões do Internet Explorer:

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

MIME Sniffing é a prática de inspecionar o conteúdo de um fluxo de bytes para deduzir o formato de arquivo dos dados nele.

Se MIME Sniffing não for desabilitado explicitamente, os invasores poderão manipular alguns navegadores para interpretar os dados de maneira inadequada, permitindo ataques de cross-site scripting. Para cada página que pode incluir conteúdo controlável pelo usuário, você deve usar o cabeçalho HTTP X-Content-Type-Options: nosniff.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a proteção contra MIME Sniffing:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

Erros de otimização do compilador ocorrem quando:

1. Dados secretos são armazenados na memória.

2. Os dados secretos são limpos da memória por meio da substituição de seu conteúdo.



3. O código-fonte é compilado com o uso de um compilador de otimização, que identifica e remove a função que substitui o conteúdo como um repositório morto porque a memória não é usada posteriormente.
Exemplo 1: O código a seguir lê uma senha do usuário, utiliza-a para se conectar a um mainframe back-end e depois tenta limpar a senha da memória usando memset().

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

O código no exemplo comporta-se de forma correta quando executado literalmente, mas, se ele for compilado com o uso de um compilador de otimização, como o Microsoft Visual C++(R) .NET ou o GCC 3.x, a chamada para memset() será removida como um repositório morto porque o buffer pwd não é usado após a substituição de seu valor [2]. Como o buffer pwd contém um valor sensível, o aplicativo poderá ficar vulnerável a ataques se os dados permanecerem residentes na memória. Se os invasores puderem acessar a região correta da memória, eles poderão usar a senha recuperada para ganhar o controle do sistema.

É uma prática comum substituir dados sensíveis manipulados na memória, como senhas ou chaves criptográficas, a fim de impedir que os invasores descubram segredos do sistema. No entanto, com o advento de compiladores de otimização, os programas nem sempre se comportam como seu código-fonte sozinho poderia sugerir. No exemplo, o compilador interpreta a chamada para memset() como um código morto, pois a memória que está sendo gravada não é utilizada depois, apesar do fato de existir claramente uma motivação de segurança para que essa operação ocorra. O problema aqui é que muitos compiladores e, na verdade, muitas linguagens de programação, não consideram esta e outras preocupações de segurança em seus esforços para melhorar a eficiência.

Em geral, os invasores exploram esse tipo de vulnerabilidade usando um despejo de memória ou um mecanismo de tempo de execução para acessar a memória usada por um aplicativo específico e recuperar as informações secretas. Depois que um invasor tem acesso às informações secretas, é relativamente simples e direto explorar ainda mais o sistema e possivelmente comprometer outros recursos com os quais o aplicativo interage.

Se uma verificação de limites de array envolver o cálculo de um ponteiro ilegal e, em seguida, a determinação de que esse ponteiro está fora dos limites, alguns compiladores otimizarão a verificação, supondo que o programador nunca criaria intencionalmente um ponteiro ilegal.

Exemplo 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

A operação buf + len é maior que 2^32 e, portanto, o valor resultante é menor que buf. Porém, como um estouro aritmético em um ponteiro é um comportamento indefinido, alguns compiladores assumirão buf + len >= buf e otimizarão a verificação de quebra de linha. Como resultado dessa otimização, o código após esse bloco pode ser vulnerável a um buffer overflow.

O aplicativo Django expõe a visualização serve do aplicativo static files, o qual não foi projetado para ser implantado em um ambiente de produção. De acordo com a documentação do Django:

"As ferramentas static files, em sua maioria, são projetadas para ajudar a fazer com que arquivos estáticos sejam implantados com êxito na produção. Isso geralmente significa um servidor de arquivos estáticos separado e dedicado, o que é bastante sobrecarga quando se refere ao desenvolvimento local. Portanto, o aplicativo staticfiles entrega com uma visualização de auxílio rápida e suja que você pode utilizar para servir arquivos localmente durante o desenvolvimento.

Essa visualização funcionará somente se DEBUG for True.

Isso porque essa visualização é extremamente ineficiente e provavelmente insegura. Isso destina-se apenas ao desenvolvimento local, e nunca deve ser usado na produção."

Os recursos de aplicativos que contenham informações confidenciais ou que ofereçam funcionalidades privilegiadas, geralmente estarão em um risco maior de exploração. Durante a fase de reconhecimento, um invasor farpa tentativas para descobrir esses arquivos e diretórios. Usar esquemas de nomeação previsíveis para tais recursos torna mais fácil para o invasor localizá-los. Todos os recursos de aplicativos que lidam com funcionalidades confidenciais, como autenticação, tarefas administrativas, ou gerenciamento de informações privadas, devem ser suficientemente protegidos contra a descoberta.

Exemplo 1: Neste exemplo, o aplicativo admin é implantado em uma URL previsível:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Os recursos responsáveis pelo armazenamento de dados devem ser separados daqueles que implementam a funcionalidade do aplicativo. Os programadores devem ter cautela ao criar recursos temporários ou de backup.

A maioria dos aplicativos da web usa um identificador de sessão para identificar exclusivamente os usuários, que normalmente é armazenado em um cookie e transmitido de forma transparente entre o servidor e o navegador da web.


Os aplicativos que não armazenam identificadores de sessão em cookies às vezes os transmitem como um parâmetro de solicitação HTTP ou como parte da URL. Aceitar identificadores de sessão especificados em URLs torna mais fácil para invasores realizar ataques de fixação de sessão.

Colocar identificadores de sessão em URLs também pode aumentar as chances de ataques de sequestro de sessão bem-sucedidos contra o aplicativo. O sequestro de sessão ocorre quando um invasor assume o controle da sessão ativa da vítima ou do identificador de sessão. É uma prática comum para servidores da web, servidores de aplicativos e proxies da web armazenar URLs solicitados. Se identificadores de sessão forem incluídos em URLs, eles também serão registrados. Aumentar o número de locais onde os identificadores de sessão são exibidos e armazenados aumenta as chances de serem comprometidos por um invasor.

Se você estiver usando o Tomcat para realizar a autenticação, o arquivo descritor de implantação do Tomcat especificará um "Realm" usado para autenticação. Parece o seguinte:

Exemplo 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

Essa tag Realm usa um atributo opcional denominado debug, que indica o nível de log. Quanto maior o número, mais detalhadas serão as mensagens de log. Se o nível de depuração estiver definido como muito alto, o Tomcat gravará todos os nomes de usuário e senhas em texto sem formatação no arquivo de log. O ponto limite para a depuração de mensagens relacionadas ao JAASRealm do Tomcat é 3 (3 ou acima é ruim, 2 ou abaixo é OK), mas esse limite pode variar para outros tipos de realms fornecidos pelo Tomcat.

Acessar diretamente as Java Server Pages (JSPs) em aplicativos construídos usando estruturas da web, como Struts ou Spring, que usam ações ou servlets para delegar solicitações a JSPs, pode resultar em exceções não tratadas e vazamentos de informações do sistema. Servidores de aplicativos mal implementados ou configurados foram cooptados para vazar detalhes do código-fonte usando solicitações especialmente criadas, como http://host/page.jsp%00 ou http://host/page.js%2570. Pior ainda, se um aplicativo permitir que os usuários carreguem arquivos arbitrários, os invasores podem usar esse mecanismo para fazer upload de código mal-intencionado na forma de um JSP e solicitar que a página carregada faça com que o código mal-intencionado seja executado no servidor.

Exemplo 1: O exemplo a seguir mostra uma restrição de segurança mal construída que permite explicitamente o acesso direto a JSPs com um '*' no nome da função, o que indica que todos os usuários têm permissão para acessar os recursos da web correspondentes.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

As funções de segurança duplicadas não têm nenhum propósito, pois apenas a última definição de uma determinada função de segurança será aplicada.
Exemplo 1: A entrada de um arquivo web.xml define duas funções admin.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Os mapeamentos de servlet duplicados não têm nenhum propósito, pois apenas a última entrada será aplicada quando o mesmo padrão de URL for usado em vários mapeamentos de servlet.

Exemplo 1: No exemplo a seguir, o padrão do URL /servletA/* é usado em dois mapeamentos de servlet diferentes.

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>