No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

Os desenvolvedores especificam dependências externas em um destino Ant usando uma tarefa <get>, que recupera a dependência especificada pelo URL correspondente. Essa abordagem é funcionalmente equivalente ao cenário em que um desenvolvedor documenta cada dependência externa como um artefato incluído no projeto de software, mas é mais desejável porque automatiza a recuperação e incorporação das dependências quando um build é executado.

Exemplo 1: O seguinte trecho de um arquivo de configuração Ant build.xml mostra uma referência típica a uma dependência externa:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de uma dependência comprometida ser introduzida em um processo de build manual, a tendência dos sistemas de build automatizados de recuperar a dependência de uma fonte externa cada vez que o sistema de compilação é executado em um novo ambiente aumenta muito a janela de oportunidade para um atacante. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

No Ivy, em vez de listar URLs explícitos dos quais recuperar as dependências, os desenvolvedores especificam os nomes e versões das dependências e o Ivy conta com sua configuração subjacente para identificar os servidores dos quais recuperar as dependências. Para componentes comumente usados, isso evita que o desenvolvedor tenha que pesquisar locais de dependência.

Exemplo 1: O trecho a seguir de um arquivo ivy.xml do Ivy mostra como um desenvolvedor pode especificar várias dependências externas usando seu nome e versão:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de introduzir uma dependência comprometida em um processo de compilação manual, a tendência dos sistemas de compilação automatizados de recuperar a dependência de uma fonte externa sempre que o sistema de compilação for executado em um novo ambiente aumenta a janela de oportunidade para um invasor. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

No Maven, em vez de listar URLs explícitos dos quais recuperar as dependências, os desenvolvedores especificam os nomes e versões das dependências e o Maven conta com sua configuração subjacente para identificar os servidores dos quais recuperar as dependências. Para componentes comumente usados, isso evita que o desenvolvedor tenha que pesquisar locais de dependência.

Exemplo 1: O trecho a seguir de um arquivo pom.xml do Maven mostra como um desenvolvedor pode especificar várias dependências externas usando seu nome e versão:

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de uma dependência comprometida ser introduzida em um processo de build manual, a tendência dos sistemas de build automatizados de recuperar a dependência de uma fonte externa cada vez que o sistema de compilação é executado em um novo ambiente aumenta muito a janela de oportunidade para um atacante. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.

O CakePHP pode ser configurado para expor informações de depuração que incluam erros, avisos, SQL, instruções e rastreamentos de pilha. Informações de depuração não devem ser usadas em ambientes de produção.

Exemplo 1:

    Configure::write('debug', 3);

O segundo parâmetro para o método Configure::write() indica o nível de depuração. Quanto maior o número, mais detalhadas serão as mensagens de log.

Quanto mais tempo uma sessão permanecer aberta, maior será janela de oportunidade que um invasor terá para comprometer as contas dos usuários. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de obter a senha de um usuário por força bruta, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão a partir de um navegador aberto. Tempos limite de sessão mais longos também podem evitar a liberação da memória e eventualmente resultar em uma negação de serviço se um número suficientemente grande de sessões for criado.

Exemplo 1: O exemplo a seguir mostra o CakePHP configurado com uma segurança de sessão low.

    Configure::write('Security.level', 'low');

Em conjunção com a configuração de Session.timeout, as configurações de Security.level definem por quanto tempo uma sessão permanece válida. A hora de tempo limite de sessão real é igual a Session.timeout vezes um dos seguintes múltiplos:

'alto' = x 10
'médio' = x 100
'baixo' = x 300

O armazenamento de um certificado de texto simples em uma configuração ou arquivo de manifesto permite que qualquer pessoa que possa ler o arquivo acesse o recurso protegido por certificado. Os desenvolvedores às vezes acreditam que não podem defender o aplicativo de alguém que tenha acesso à configuração, mas essa atitude torna o trabalho do invasor mais fácil. Boas diretrizes de gerenciamento de certificados exigem que um certificado nunca seja armazenado em texto simples.

A manipulação de ClassLoader permite que um invasor acesse e modifique as configurações do servidor de aplicativos subjacentes. Em certos servidores de aplicativos como o Tomcat 8, um invasor pode ajustar essas configurações para carregar um shell da web e executar comandos arbitrários.

A falsificação de DNS, também conhecida como envenenamento de chache DNS, é um tipo de ataque no qual um invasor corrompe o cache do resolvedor DNS, fazendo com que ele retorne endereços IP incorretos. Usando a falsificação de DNS, um invasor pode redirecionar usuários para sites mal-intencionados sem o seu conhecimento. No contexto do JavaScript do lado do servidor usando Node.js, o manuseio inadequado das configurações do servidor DNS pode levar a vulnerabilidades de segurança.

Exemplo 1: Considere um cenário em que um aplicativo Node.js permite que os usuários especifiquem servidores DNS personalizados. Se essa entrada não for devidamente validada e higienizada, um invasor poderá fornecer servidores DNS mal-intencionados e implementar ataques de falsificação de DNS.

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

Neste exemplo, a variável customDnsServers recebe um valor derivado da entrada controlada pelo usuário. Em seguida, essa entrada é usada para configurar os servidores DNS usando dns.setServers(customDnsServers). Se um invasor fornecer endereços de servidores DNS mal-intencionados, ele poderá direcionar o aplicativo para resolver nomes de domínio usando seus servidores, o que pode retornar endereços IP falsos.

Quando um Dockerfile não especifica um USER, os contêineres do Docker são executados com privilégios de superusuário por padrão. Esses privilégios de superusuário são propagados para o código em execução dentro do contêiner, o que geralmente é mais permissão do que o necessário. A execução do contêiner do Docker com privilégios de superusuário amplia a superfície de ataque que pode permitir que invasores executem formas mais sérias de exploração.

Dockerfiles podem especificar um intervalo ilimitado de versões para dependências e imagens de base. Se um invasor for capaz de adicionar versões mal-intencionadas de dependências a um repositório ou enganar o sistema de compilação para fazer o download de dependências de um repositório sob o controle do invasor, se o docker estiver configurado sem versões específicas das dependências, então o docker baixará e executará silenciosamente a dependência comprometida .

Esse tipo de fraqueza pode ser explorado como resultado de um ataque à cadeia de suprimentos em que os invasores podem aproveitar a configuração incorreta dos desenvolvedores, typosquatting [sequestro de URL] e podem adicionar pacotes mal-intencionados a repositórios de código-fonte aberto. Um ataque desse tipo explora a confiança nos pacotes publicados para obter acesso e exfiltrar dados.

No docker, a tag latest indica automaticamente o nível de versão de uma imagem que não usa uma tag de resumo ou exclusiva para fornecer uma versão para ela. O Docker atribui automaticamente a tag latest como mecanismo para apontar para o arquivo de manifesto de imagem mais recente. Como as tags são mutáveis, um invasor pode substituir uma imagem ou camada usando uma tag latest (ou tags fracas, como imagename-lst, imagename-last, myimage).

Exemplo 1: A configuração a seguir instrui o Docker a escolher a imagem de base usando a versão mais recente do ubuntu.

    FROM ubuntu:Latest
    ...

O Docker não valida se o repositório configurado para suportar o gerenciador de pacotes é confiável.

Exemplo 2: A seguinte configuração instrui o gerenciador de pacotes zypper a recuperar a versão mais recente do pacote fornecido.

...
zypper install package
...

No Example 2, se o repositório estiver comprometido, um invasor pode simplesmente fazer upload de uma versão que atenda aos critérios dinâmicos e fazer com que o zypper baixe uma versão mal-intencionada da dependência.

O Dockerfile com a instrução USER definida como raiz tem um privilégio excessivamente permissivo para fazer alterações dentro do contêiner. Isso viola o princípio de execução de imagens com o mínimo de privilégios. Em casos normais, as permissões de raiz podem ser necessárias para instalar pacotes e criar pastas. Após a conclusão da instalação, uma boa prática é adicionar um usuário com privilégios restritos.

Por padrão, o Docker permite vincular portas privilegiadas a um contêiner e, se uma porta não for declarada pelo usuário, o Docker mapeia a porta do contêiner para uma disponível no intervalo 49153-65535. Em muitos casos, certas portas precisam ser abertas para a execução de serviços e, com o tempo, o número de portas abertas pode aumentar. Portas abertas aumentam a superfície de ataque, especialmente para serviços executados com privilégios mais altos. Certifique-se de abrir apenas as portas necessárias para esse serviço específico. Quando os serviços não exigem privilégios mais altos, execute-os na porta fora do intervalo de portas privilegiadas.

Você pode reconstruir um Dockerfile a partir de uma imagem docker disponível publicamente usando inspeção de docker e o comando history ou automatizando esse processo por meio de uma ferramenta de terceiros. Se forem adicionadas informações confidenciais usando o comando ADD/COPY, um invasor pode recriar cada camada do docker para obter as informações.

Usar Volumes também pode expor diretórios confidenciais. Se você precisa usar Volumes para persistir os dados, evite montar diretórios confidenciais.

Quando um serviço Secure Shell (SSH) está sendo executado em um contêiner, é difícil gerenciar políticas de acesso, chaves, senhas e atualizações de segurança.

Usar uma CDN para servir um aplicativo dependente de JavaScript oferece muito mais vantagens que servir o JavaScript do próprio servidor do aplicativo. Essas vantagens incluem a melhoria do desempenho e a redução da manutenção do código para o proprietário do aplicativo. No entanto, o aplicativo supõe que a CDN distribuirá conteúdo seguro para o navegador. Se um invasor comprometer uma CDN, ela enviará código mal-intencionado ao navegador do usuário. O navegador do usuário passará a executar um código que o aplicativo não pode controlar ou detectar como mal-intencionado.

Exemplo 1: O código ASPX a seguir inclui o código jQuery da Microsoft referenciando a Microsoft CDN:

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

Exemplo 2: O código ASPX a seguir permite o redirecionamento automático de todas as solicitações de script da estrutura ASP.NET à Microsoft Ajax CDN:

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

No Example 2, o controle ScriptManager configura sua página ASPX para redirecionar automaticamente qualquer solicitação de script à CDN apropriada.

Se você estiver usando o Blaze DS para realizar o registro em log de eventos inesperados, o arquivo descritor services-config.xml especificará um elemento XML "Logging" para descrever vários aspectos desse registro. Parece o seguinte:

Exemplo 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

Essa tag target usa um atributo opcional denominado level, que indica o nível de log. Se o nível de depuração for definido com um nível muito detalhado, seu aplicativo pode gravar dados confidenciais no arquivo de log.

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

Conceder acesso ou funções do BigQuery ao tipo principal especial, como allUsers e allAuthenticatedUsers, dá a qualquer pessoa acesso a dados confidenciais.

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