Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

Nomes e valores de propriedades de bean precisam ser validados antes do preenchimento de qualquer bean. Funções de preenchimento de beans permitem que os desenvolvedores definam uma propriedade de bean ou uma propriedade aninhada. Os invasores podem utilizar essa funcionalidade para acessar propriedades especiais de beans, como class.classLoader, o que permitirá que ele substitua as propriedades do sistema e potencialmente execute código arbitrário.

Exemplo 1: O código a seguir define uma propriedade de bean controlada pelo usuário sem a devida validação do nome da propriedade ou do valor:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

A autenticação baseada em ID de toque pode ser implementada de duas formas diferentes: usando a estrutura LocalAuthentication ou usando os controles de acesso baseados em ID de toque no serviço de conjunto de chaves.

Embora os dois devam ser fortes o suficiente para a maioria dos aplicativos, a abordagem LocalAuthentication tem algumas características que as tornam menos adequadas para aplicativos de alto risco, como bancos, médicos e seguros:

- LocalAuthentication é definida fora do Enclave Seguro do dispositivo, o que implica que as APIs podem ser conectadas e modificadas em dispositivos com jailbreak.
- LocalAuthentication autentica o usuário avaliando a política de contexto que só pode avaliar como true ou false. Essa avaliação booleana implica que o aplicativo não será capaz de saber quem está realmente sendo autenticado, ele só sabe se a impressão digital que está registrada com o dispositivo foi usada. Além disso, as impressões digitais que poderiam ser registradas no futuro serão avaliadas com êxito como true.


Exemplo 1: O seguinte código usa a estrutura LocalAuthentication para realizar a autenticação do usuário:

    ...
    LAContext *context = [[LAContext alloc] init];  
    NSError *error = nil;  
    NSString *reason = @"Please authenticate using the Touch ID sensor.";
    
    if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {  
        [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
            localizedReason:reason
                reply:^(BOOL success, NSError *error) {
                    if (success) {
                        // Fingerprint was authenticated
                    } else {
                        // Fingerprint could not be authenticated
                    }
            }
        ];
    ...

A autenticação baseada em ID de toque pode ser implementada usando os serviços de conjunto de chaves armazenando um item no conjunto de chaves e definindo um controle de acesso que requer que o usuário use sua impressão digital para recuperar o item posteriormente. As seguintes políticas podem ser usadas para definir como o usuário será autenticado usando sua impressão digital:

- kSecAccessControlUserPresence: Restrição para acessar usando a ID de toque ou a senha. A ID de toque não precisa estar disponível ou registrada. O item ainda estará acessível pela ID de toque, mesmo se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDAny: Restrição para acessar usando a ID de toque para quaisquer impressões digitais registradas. O item não será invalidado se as impressões digitais forem adicionadas ou removidas.
- kSecAccessControlTouchIDCurrentSet: Restrição para acessar usando a ID de toque para as impressões digitais registradas no momento. O item será invalidado se as impressões digitais forem adicionadas ou removidas.

Ao usar a ID de toque, você deve usar o atributo kSecAccessControlTouchIDCurrentSet para proteger contra a adição ou remoção de impressões digitais no futuro.

Exemplo 1: O seguinte código usa a restrição kSecAccessControlTouchIDAny que permite que todas as impressões digitais cadastradas no futuro desbloqueiem o item de conjunto de chaves:

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

De acordo com a política da Apple, o aplicativo deve sempre explicar aos usuários por que suas impressões digitais são necessárias. Não fazer isso pode confundir o usuário ou mesmo fazer com que o aplicativo seja rejeitado na AppStore.

Exemplo 1: O código a seguir usa a ID de toque para autenticar o usuário, mas não fornece um motivo localizado que explique porque a autenticação é necessária:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

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

Em geral, vulnerabilidades de buffer overflow ocorrem em um código que:

- Baseia-se em dados externos para controlar seu comportamento.

- Depende de propriedades dos dados que são aplicados fora do escopo imediato do código.

- É tão complexo que um programador não consegue prever seu comportamento com precisão.



Os exemplos a seguir demonstram todos esses três cenários.

Exemplo 1.a: O exemplo de código a seguir demonstra um buffer overflow simples que muitas vezes é causado pelo primeiro cenário, em que o código se baseia em dados externos para controlar seu comportamento. O código usa a função gets() para ler uma quantidade arbitrária de dados em um buffer de pilha. Como não há nenhuma maneira de limitar a quantidade de dados lida por essa função, a segurança do código depende de o usuário sempre inserir menos de BUFSIZE caracteres.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

Exemplo 1.b: Este exemplo mostra como é fácil imitar o comportamento não seguro da função gets() em C++ usando o operador >> para ler a entrada em uma string char[].

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

Exemplo 2: O código neste exemplo também se baseia na entrada do usuário para controlar seu comportamento, mas adiciona um certo nível de desvio com o uso da função de cópia de memória limitada memcpy(). Essa função aceita um buffer de destino, um buffer de origem e o número de bytes a serem copiados. O buffer de entrada é preenchido por uma chamada limitada para read(), mas o usuário especifica o número de bytes que são copiados por memcpy().

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

Observação: Esse tipo de vulnerabilidade de buffer overflow (em que um programa lê os dados e depois confia em um valor desses dados em operações de memória subsequentes nos dados restantes) apareceu com uma determinada frequência em bibliotecas de imagem e áudio e também em outras bibliotecas de processamento de arquivos.

Exemplo 3: Este é um exemplo do segundo cenário, no qual o código depende de propriedades dos dados que não são verificadas localmente. Neste exemplo, uma função denominada lccopy() usa uma string como seu argumento e retorna uma cópia alocada por heap dessa string com letras maiúsculas convertidas em minúsculas. A função não realiza verificações de limites em sua entrada, pois espera que str sempre seja menor que BUFSIZE. Se um invasor ignorar as verificações no código que chama lccopy() ou se uma mudança nesse código tornar inválida a suposição sobre o tamanho de str, lccopy() fará o estouro de buf com a chamada ilimitada para strcpy().

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

Exemplo 4: O código a seguir demonstra o terceiro cenário em que o código é tão complexo que seu comportamento não pode ser facilmente previsto. Esse código vem do popular decodificador de imagens libPNG, que é usado por uma ampla variedade de aplicativos.

O código parece realizar a verificação de limites com segurança, pois verifica o tamanho do comprimento de variáveis, que ele utiliza mais tarde para controlar a quantidade de dados copiada por png_crc_read(). No entanto, logo antes de testar o comprimento, o código realiza uma verificação em png_ptr->mode e, se essa verificação falhar, um aviso será emitido e o processamento continuará. Como length é testado em um bloco else if, length não poderá ser testado se a primeira verificação falhar e será usado às cegas na chamada para png_crc_read(), possivelmente permitindo um buffer overflow de pilha.

Embora o código nesse exemplo não seja o mais complexo que vimos até agora, ele demonstra por que a complexidade deve ser minimizada no código que realiza operações de memória.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

Exemplo 5: Este exemplo também demonstra o terceiro cenário, no qual a complexidade do programa o expõe a estouros de buffer. Nesse caso, a exposição é decorrente da interface ambígua de uma das funções, e não da estrutura do código (como foi o caso no exemplo anterior).

A função getUserInfo() usa um nome de usuário especificado como uma string de vários bytes e um apontador para uma estrutura de informações do usuário e preenche essa estrutura com informações sobre o usuário. Como a autenticação do Windows usa Unicode para nomes de usuário, o argumento username é primeiro convertido de uma string de vários bytes em uma string Unicode. Em seguida, essa função transmite incorretamente o tamanho de unicodeUser em bytes em vez de em caracteres. Portanto, a chamada para MultiByteToWideChar() pode gravar caracteres com um comprimento de até (UNLEN+1)*sizeof(WCHAR), ou
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, na matriz unicodeUser, que tem apenas (UNLEN+1)*sizeof(WCHAR) bytes alocados. Se a string username contiver mais de UNLEN caracteres, a chamada para MultiByteToWideChar() causará um estouro no buffer unicodeUser.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

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 grave além dos limites da memória alocada.

Exemplo 1: Exemplo: O código a seguir estoura c porque o tipo double requer mais espaço do que está alocado para c.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

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 grave além dos limites da memória alocada.

Exemplo 1: O código a seguir estoura buf porque, dependendo do tamanho de f, o especificador de string de formato"%d %.1f ... " pode exceder a quantidade de memória alocada.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

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 erro "off-by-one" 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 de pilha, 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.

Exemplo 1: O código a seguir contém um estouro de buffer "off-by-one", que ocorre quando recv retorna os bytes máximos permitidos de sizeof(buf) que foram lidos. Nesse caso, a desreferência subsequente de buf[nbytes] gravará o byte null fora dos limites da memória alocada.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

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.

Exemplo 1: O código a seguir tenta evitar um estouro de buffer de leitura "off-by-one", verificando se o valor não confiável lido de getInputLength() é menor que o tamanho do buffer de destino output. No entanto, como a comparação entre len e MAX é assinada, se len for negativo, ele se tornará um número positivo muito grande quando for convertido em um argumento sem sinal para memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

O sistema de gerenciamento de dependência automatizado Apache Ivy permite que os usuários especifiquem um status de versão para uma dependência em vez de listar o específico, o que é conhecido como revisão dinâmica. Se um invasor for capaz de comprometer o repositório de dependências ou enganar o sistema de compilação para baixar as dependências de um repositório sob controle do invasor, um especificador de revisão dinâmica pode ser tudo o que é necessário para o sistema de compilação baixar e executar silenciosamente a dependência comprometida. Além dos riscos de segurança, as revisões dinâmicas também introduzem um elemento de risco na frente da qualidade do código: As revisões dinâmicas colocam a segurança e a estabilidade de seu software sob o controle de terceiros que desenvolvem e lançam as dependências que seu software usa.

No momento da compilação, o Ivy se conecta ao repositório e tenta recuperar uma dependência que corresponda ao status listado.

O Ivy aceita os seguintes especificadores de revisão dinâmica:

- latest.integration: Seleciona a revisão mais recente do módulo de dependência.
- latest.[any status]: Seleciona a revisão mais recente do módulo de dependência com o status especificado, no mínimo. Por exemplo, latest.milestone selecionará a versão mais recente que seja um marco ou um lançamento, e latest.release selecionará apenas a versão mais recente.
- Qualquer revisão que termine em +: Seleciona a última sub-revisão do módulo de dependência. Por exemplo, se a dependência existe nas revisões 1.0.3, 1.0.7 e 1.1.2, uma revisão especificada como 1.0.+ selecionará a revisão 1.0.7.
- Intervalos de versão: A notação matemática para intervalos, como < e >, pode ser usada para corresponder a um intervalo de versões.

Exemplo 1: A seguinte entrada de configuração instrui o Ivy a recuperar a versão de lançamento mais recente do componente clover:

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

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 Ivy baixe uma versão mal-intencionada da dependência.

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

Mesmo que o Castor crie um bloqueio em um objeto, ele não impede que outros threads leiam ou gravem nele. Consultas somente leitura também são cerca de 7 vezes mais rápidas em comparação ao modo compartilhado padrão.

Exemplo 1: O exemplo a seguir especifica o modo de consulta como SHARED, o que permite acesso de leitura e gravação.

results = query.execute(Database.SHARED);