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.

Vulnerabilidades de string de formato ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são transmitidos como o argumento de string de formato para uma função como sprintf(), FormatMessageW() ou syslog().
Exemplo 1: O código a seguir copia um argumento de linha de comando em um buffer usando snprintf().

int main(int argc, char **argv){
	char buf[128];
	...
	snprintf(buf,128,argv[1]);
}

Esse código permite que um invasor visualize o conteúdo da pilha e grave nessa pilha usando um argumento de linha de comando que contém uma sequência de diretivas de formatação. O invasor pode ler a partir da pilha fornecendo mais diretivas de formatação, como %x, do que a função utiliza como argumentos a serem formatados. (Neste exemplo, a função não usa argumentos a serem formatados.) Ao usar a diretiva de formatação %n, o invasor pode gravar na pilha, fazendo com que snprintf() grave no argumento especificado o número de bytes cuja saída foi processada até o momento (em vez de ler um valor do argumento, que é o comportamento pretendido). Uma versão sofisticada desse ataque usará quatro gravações escalonadas para controlar completamente o valor de um apontador na pilha.

Exemplo 2: Certas implementações facilitam ainda mais alguns ataques mais avançados, fornecendo diretivas de formato que controlam a localização na memória na qual realizar leituras ou gravações. Um exemplo dessas diretivas é mostrado no código a seguir, escrito para glibc:

	printf("%d %d %1$d %1$d\n", 5, 9);

Esse código produz a seguinte saída:

5 9 5 5

Também é possível usar meias-gravações (%hn) para controlar com precisão DWORDS arbitrários na memória, o que reduz significativamente a complexidade necessária para executar um ataque que, de outra forma, exigiria quatro gravações escalonadas, como o mencionado no Example 1.

Exemplo 3: As vulnerabilidades de string de formato simples muitas vezes são resultantes de atalhos aparentemente inofensivos. O uso de alguns desses atalhos é tão arraigado que os programadores talvez nem mesmo percebam que a função que eles estão usando espera um argumento de string de formato.

Por exemplo, a função é syslog() por vezes utilizada da seguinte maneira:

	...
	syslog(LOG_ERR, cmdBuf);
	...

Como o segundo parâmetro para syslog() é uma string de formato, qualquer diretiva de formatação incluída em cmdBuf é interpretada conforme descrito no Example 1.

O código a seguir mostra o uso correto de syslog():

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa acesse valores fora dos limites da memória alocada.

Exemplo 1: O exemplo a seguir lê valores arbitrários da pilha, porque o número de especificadores de formato não está alinhado ao número de argumentos transmitidos para a função.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa converta valores de dados ou acesse valores fora dos limites da memória alocada.

Exemplo 1: O código a seguir converte incorretamente f de um flutuador usando um especificador de formato %d.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

Processadores de planilha populares, como o Apache OpenOffice Calc e o Microsoft Office Excel, oferecem suporte a operações de fórmula poderosas que podem permitir que invasores em controle da planilha executem comandos arbitrários no sistema subjacente ou que podem provocar o vazamento de informações confidenciais na planilha.

Como exemplo, o invasor pode injetar a seguinte carga útil como parte de um campo CSV: =cmd|'/C calc.exe'!Z0. Se o usuário que abrir a planilha confiar na origem do documento, poderá aceitar todos os prompts de segurança apresentados pelo processador de planilha e deixar a carga útil (neste exemplo, a abertura da calculadora do Windows) ser executada em seu sistema.

Exemplo 1: O exemplo a seguir mostra um controlador Spring que gera uma resposta CSV com dados não sanitizados, controlados pelo usuário:

    @RequestMapping(value = "/api/service.csv")
    public ResponseEntity<String> service(@RequestParam("name") String name) {

        HttpHeaders responseHeaders = new HttpHeaders();
        responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
        responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");

        String data = generateCSVFor(name);

        return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
    }

Um aplicativo malicioso pode invocar uma PreferenceActivity insegura e fornecê-la com uma Intenção :android:show_fragment extra a fim de fazê-lo carregar uma classe arbitrária. O aplicativo malicioso pode tornar a carga de PreferenceActivity um Fragment arbitrário do aplicativo vulnerável que, normalmente, é carregado em uma Atividade não exportada, expondo-a ao invasor.

Exemplo 1: O código a seguir falha ao implementar uma verificação para verificar se somente fragmentos esperados são carregados.

@Override
public static boolean isFragmentValid(Fragment paramFragment)
{
    return true;
}

Vulnerabilidades de falsificação de quadros ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável.

2. Os dados são usados como uma URL de iframe sem serem validados.

Dessa forma, um invasor pode ser capaz de controlar o que é renderizado no quadro embutido. Modificando a URL do quadro de forma que ela aponte para um site mal-intencionado, ataques de phishing podem ser realizados em uma tentativa de roubar informações do usuário, incluindo credenciais ou outros dados confidenciais. Considerando que o domínio base é confiável - Salesforce.com, a vítima confiará na página e fornecerá todas as informações solicitadas.

Exemplo 1: No exemplo de código a seguir, o parâmetro de URL iframesrc é utilizado diretamente como a URL de destino de apex:iframe.

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>

Dessa forma, se um invasor fornece a uma vítima o parâmetro iframesrc definido como um site mal-intencionado, o quadro será renderizado com o conteúdo desse site mal-intencionado.

<iframe src="http://evildomain.com/">

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

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

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 a allUsers ou allAuthenticatedUsers uma função de CryptoKey do Cloud KMS 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

Os backups de banco de dados são essenciais para proteger contra perda ou corrupção de dados. Os backups automatizados de uma instância de banco de dados do Cloud SQL devem ser configurados e habilitados explicitamente.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita as configurações de backup de instância de banco de dados definindo enabled como false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    backup_configuration {
      enabled = false
      ...
    }
  }
}

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.

Por padrão, o Terraform implanta uma instância do Banco de Dados do Google Cloud SQL que aceita apenas conexões de endereços IP privados. As configurações opcionais de Redes Autorizadas definem intervalos aceitáveis de endereços IP públicos.

Exemplo 1: A configuração do Terraform a seguir define value como 0.0.0.0/0 no bloco authorized_networks. Um bloco CIDR de /0 aceita conexões de qualquer endereço IP entre 0.0.0.0 e 255.255.255.255.

resource "google_sql_database_instance" "db-demo" {
  ...
  settings {
  ...
    ip_configuration {
    ...
      authorized_networks {
        name  = "any ip"
        value = "0.0.0.0/0"
      }
    ...
    }
    ...
  }
  ...
}

Conceder a allUsers ou allAuthenticatedUsers uma função do Cloud Storage dá a qualquer pessoa acesso a dados confidenciais.

A má gestão de permissões aumenta o risco de acesso não autorizado ou modificação de dados restritos.

Para definir a permissão do usuário para acesso a buckets e objetos em buckets, o Google Cloud Storage oferece dois sistemas: ACLs (Listas de Controle de Acesso) e IAM (Gerenciamento de Identidade e Acesso). O IAM pode ser usado em todo o Google Cloud, enquanto apenas o Cloud Storage oferece suporte a ACLs. Habilitar o Acesso Uniforme no Nível do Bucket impede que as ACLs concedam permissão. Isso garante que o IAM seja o único sistema para gerenciar todo o controle de acesso dos recursos do Google Cloud.

Exemplo 1: A configuração do Terraform a seguir permite o uso de ACLs junto com o IAM para conceder acesso ao bucket de armazenamento definindo uniform_bucket_level_access como false.

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

O controle de acesso baseado no IAM reduz os erros humanos e promove a eficiência. A habilitação do login do SO permite o uso de funções do IAM para automatizar o gerenciamento do ciclo de vida de contas do Linux para acessar todas as instâncias do Compute Engine no mesmo projeto ou organização.

Exemplo 1: O exemplo a seguir mostra uma configuração do Terraform que desabilita o uso de funções do IAM para gerenciar o acesso ao SSH definindo enable-oslogin como false no argumento metadata.

resource "google_compute_instance" "compute-instance-demo" {
  ...
  metadata = {
    enable-oslogin = false
    ...
  }
  ...
}