Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa a entrada de propriedades do sistema para definir a máscara de permissão padrão. Se os invasores puderem alterar as propriedades do sistema, eles poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao alterar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: O trecho a seguir é um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.

   flash.system.Security.allowDomain("*");

O uso de * como argumento para allowDomain() indica que os dados do aplicativo estão acessíveis a outros aplicativos SWF de qualquer domínio.

Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. A partir do Flash Player 9.0.124.0, a Adobe também introduziu a capacidade de definir quais cabeçalhos personalizados o Flash Player pode enviar entre domínios. No entanto, é preciso ter cuidado ao definir essas configurações porque uma política de cabeçalhos personalizados excessivamente permissiva, quando aplicada junto com a política de vários domínios excessivamente permissiva, permitirá que um aplicativo mal-intencionado envie cabeçalhos de sua escolha para o aplicativo de destino, levando, possivelmente, a um variedade de ataques ou causando erros na execução do aplicativo que não saberá como tratar os cabeçalhos recebidos.

Exemplo 1: A configuração a seguir mostra o uso de um caractere curinga para especificar quais cabeçalhos o Flash Player pode enviar entre domínios.

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

Usar * como o valor do atributo de headers indica que qualquer cabeçalho será enviado entre domínios.

Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao decidir quem pode influenciar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques. Vulnerabilidades de desvio de restrições de política ocorrem quando:

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

2. Os dados são utilizados para carregar ou modificar configuração de política entre domínios.
Exemplo 1: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado como a URL a partir da qual carregar o arquivo de política entre domínios.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

Exemplo 2: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado com o objetivo de definir a lista de domínios confiáveis.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

A partir do Flash Player 7, aplicativos SWF carregados via HTTP não podem acessar dados de aplicativos SWF carregados via HTTPS por padrão. O Adobe Flash permite que os desenvolvedores alterem essa restrição programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao definir essas configurações, pois aplicativos SWF carregados via HTTP estão sujeitos a ataques do tipo MITM (man-in-the-middle) e, portanto, não devem ser confiáveis.

Exemplo: O código a seguir chama allowInsecureDomain(), que desativa a restrição que impede aplicativos SWF carregados via HTTP de acessar os dados de aplicativos SWF carregados via HTTPS.

   flash.system.Security.allowInsecureDomain("*");

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:

<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: 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: O código a seguir converte incorretamente f de um flutuante 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);
   ...
}

As extensões de teclado têm permissão para ler todas as teclas que um usuário pressiona. Os teclados de terceiros são normalmente usados para facilitar a entrada de texto ou para adicionar emojis adicionais, e eles podem registrar em log o que o usuário insere ou até mesmo enviar esses logs para um servidor remoto para processamento. Os teclados mal-intencionados também podem ser distribuídos para atuar como um keylogger e ler todas as teclas pressionadas pelo usuário, a fim de roubar dados confidenciais, como credenciais ou números de cartão de crédito.

O serviço de backup do Android permite que o aplicativo salve dados persistentes em um armazenamento remoto em nuvem para fornecer um ponto de restauração para os dados do aplicativo no futuro.

Os aplicativos Android podem ser configurados com este serviço de backup, definindo o atributo allowBackupcomo true (o valor padrão) e definindo o atributo backupAgent na tag do <application>.

O Android, entretanto, não garante a segurança dos seus dados durante o uso do backup, já que o armazenamento e transporte em nuvem variam de dispositivo para dispositivo.

Arquivos salvos no armazenamento externo são legíveis publicamente e podem ser modificados pelo usuário quando permitem que armazenamento em massa via USB transfira arquivos em um computador. Além disso, os arquivos no cartão de armazenamento externo permanecerão lá até mesmo após a desinstalação do aplicativo que os gravou. Essas limitações podem comprometer informações confidenciais gravadas no armazenamento ou permitir que os invasores injetem dados mal-intencionados no programa, modificando um arquivo externo no qual ele se baseia.

Exemplo 1: No código a seguir, Environment.getExternalStorageDirectory() retorna uma referência ao armazenamento externo do dispositivo Android.

 private void WriteToFile(String what_to_write) {
        try{
            File root = Environment.getExternalStorageDirectory();
            if(root.canWrite()) {
                File dir = new File(root + "write_to_the_SDcard");
                File datafile = new File(dir, number + ".extension");
                FileWriter datawriter = new FileWriter(datafile);
                BufferedWriter out = new BufferedWriter(datawriter);
                out.write(what_to_write);
                out.close();
             }
        }
   }

Os dados armazenados no armazenamento interno do Android usando MODE_WORLD_READBLE ou MODE_WORLD_WRITEABLE podem ser acessados por todos os aplicativos no dispositivo. Isso não só nega proteção contra corrupção de dados, como também, no caso de informações confidenciais, viola preocupações com a privacidade e a segurança do usuário.

Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Os níveis de acessibilidade que não contêm o ThisDeviceOnly serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo estiver ligado e desbloqueado, mas o item de conjunto de chaves será armazenado em backup no iCloud e em backups não criptografados do iTunes:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as sem criptografia em um armazenamento compartilhado inseguro.

Exemplo 1: O código a seguir instala o cache de resposta HTTP(S) no espaço de armazenamento compartilhado:

    protected void onCreate(Bundle savedInstanceState) {
       ...

       try {
           File httpCacheDir = new File(context.getExternalCacheDir(), "http");
           long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
           HttpResponseCache.install(httpCacheDir, httpCacheSize);
       } catch (IOException e) {
           Log.i(TAG, "HTTP response cache installation failed:" + e);
       }
    }

    protected void onStop() {
       ...

       HttpResponseCache cache = HttpResponseCache.getInstalled();
       if (cache != null) {
           cache.flush();
       }
   }

As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
Os desenvolvedores podem pensar que ao definir as propriedades diskCapacity ou memoryCapacity da classe URLCache como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.

A API de Proteção de dados foi projetada para permitir que os aplicativos declarem quando os itens no conjunto de chaves e os arquivos armazenados no sistema de arquivos deveriam estar acessíveis. Ela está disponível para a maioria dos arquivos de banco de dados e APIs, incluindo NSFileManager, CoreData, NSData e SQLite. Ao especificar uma das quatro classes de proteção a um determinado recurso, um desenvolvedor pode instruir o sistema de arquivos subjacente para criptografá-lo usando uma chave derivada da UID do dispositivo e a senha do usuário ou usando uma chave baseada exclusivamente no UID do dispositivo (bem como quando descriptografá-lo automaticamente).

As classes de Proteção de dados são definidas para o NSFileManager como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey em um NSDictionary associado à instância do NSFileManager, e os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções do NSFileManager, incluindo setAttributes:ofItemAtPath:error:, attributesOfItemAtPath:error: e createFileAtPath:contents:attributes:. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData como NSDataWritingOptions que podem ser transmitidas como o argumento options para as funções NSDatawriteToURL:options:error: e writeToFile:options:error:. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager e do NSData são as seguintes:

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
O recurso é armazenado no disco em um formato criptografado e não pode ser lido, ou gravado enquanto o dispositivo estiver bloqueado ou inicializando.
Disponível em iOS 4.0 ou posterior.
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
O recurso é armazenado no disco em um formato criptografado. Os recursos podem ser criados enquanto o dispositivo estiver bloqueado, mas uma vez fechado, não poderá ser aberto novamente até que o dispositivo seja desbloqueado. Se o recurso estiver aberto ao ser desbloqueado, você poderá continuar a acessar o recurso normalmente, mesmo que o usuário bloqueie o dispositivo.
Disponível em iOS 5.0 ou posterior.
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
O recurso é armazenado no disco em um formato criptografado e só poderá ser acessado depois do dispositivo inicializar. Depois que o usuário desbloquear o dispositivo pela primeira vez, o aplicativo poderá acessar o recurso e continuar a acessá-lo mesmo que o usuário bloqueie o dispositivo logo em seguida.
Disponível em iOS 5.0 ou posterior.
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
O recurso não tem proteções especiais associadas a ele. Ele pode ser lido ou gravado a qualquer momento.
Disponível em iOS 4.0 ou posterior.

Então, enquanto marcar um arquivo com NSFileProtectionCompleteUnlessOpen ou NSFileProtectionCompleteUntilFirstUserAuthentication garantirá a encriptação deles por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de NSFileProtectionCompleteUnlessOpen ou NSFileProtectionCompleteUntilFirstUserAuthentication devem ser estudados cautelosamente para determinar se uma proteção aprofundada com o NSFileProtectionComplete é garantida.

Exemplo 1: Neste exemplo, o arquivo só está protegido até que o usuário ligue o dispositivo e digite a senha pela primeira vez (até a próxima reinicialização):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionCompleteUntilFirstUserAuthentication forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...

Exemplo 2: Neste exemplo, os dados só estão protegidos até que o usuário ligue o dispositivo e digite a senha pela primeira vez (até a próxima reinicialização):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication error:&err];
...

As constantes de acessibilidade do conjunto de chaves são projetadas para permitir que os aplicativos declarem quando os itens no conjunto de chaves devem estar acessíveis. Ao especificar uma das constantes de acessibilidade de um determinado item de conjunto de chaves, um desenvolvedor pode instruir o sistema de arquivos subjacente para criptografá-lo usando uma chave derivada do UID do dispositivo e da senha do usuário ou usando uma chave baseada exclusivamente no UID do dispositivo (bem como ao descriptografá-lo automaticamente).

As constantes de acessibilidade do conjunto de chaves devem ser atribuídas como o valor da chave kSecAttrAccessible no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:

-kSecAttrAccessibleAfterFirstUnlock:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Portanto, enquanto marcar um item de conjunto de chaves com kSecAttrAccessibleAfterFirstUnlock garantirá criptografá-lo por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de kSecAttrAccessibleAfterFirstUnlock devem ser estudados cautelosamente para determinar se uma proteção aprofundada é garantida.

Exemplo 1: Neste exemplo, o item de conjunto de chaves só estará protegido até que o usuário ligue o dispositivo e digite a senha pela primeira vez (até a próxima reinicialização):

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

A API de Proteção de dados foi projetada para permitir que os aplicativos declarem quando os itens no conjunto de chaves e os arquivos armazenados no sistema de arquivos deveriam estar acessíveis. Ela está disponível para a maioria dos arquivos de banco de dados e APIs, incluindo NSFileManager, CoreData, NSData e SQLite. Ao especificar uma das quatro classes de proteção a um determinado recurso, um desenvolvedor pode instruir o sistema de arquivos subjacente para criptografá-lo usando uma chave derivada da UID do dispositivo e a senha do usuário ou usando uma chave baseada exclusivamente no UID do dispositivo (bem como quando descriptografá-lo automaticamente).

As classes de Proteção de dados são definidas para o NSFileManager como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey em um NSDictionary associado à instância do NSFileManager, e os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções do NSFileManager, incluindo setAttributes:ofItemAtPath:error:, attributesOfItemAtPath:error: e createFileAtPath:contents:attributes:. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData como NSDataWritingOptions que podem ser transmitidas como o argumento options para as funções NSDatawriteToURL:options:error: e writeToFile:options:error:. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager e do NSData são as seguintes:

-NSFileProtectionComplete, NSDataWritingFileProtectionComplete:
O recurso é armazenado no disco em um formato criptografado e não pode ser lido, ou gravado enquanto o dispositivo estiver bloqueado ou inicializando.
Disponível em iOS 4.0 ou posterior.
-NSFileProtectionCompleteUnlessOpen, NSDataWritingFileProtectionCompleteUnlessOpen:
O recurso é armazenado no disco em um formato criptografado. Os recursos podem ser criados enquanto o dispositivo estiver bloqueado, mas uma vez fechado, não poderá ser aberto novamente até que o dispositivo seja desbloqueado. Se o recurso estiver aberto ao ser desbloqueado, você poderá continuar a acessar o recurso normalmente, mesmo que o usuário bloqueie o dispositivo.
Disponível em iOS 5.0 ou posterior.
-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication:
O recurso é armazenado no disco em um formato criptografado e só poderá ser acessado depois do dispositivo inicializar. Depois que o usuário desbloquear o dispositivo pela primeira vez, o aplicativo poderá acessar o recurso e continuar a acessá-lo mesmo que o usuário bloqueie o dispositivo logo em seguida.
Disponível em iOS 5.0 ou posterior.
-NSFileProtectionNone, NSDataWritingFileProtectionNone:
O recurso não tem proteções especiais associadas a ele. Ele pode ser lido ou gravado a qualquer momento.
Disponível em iOS 4.0 ou posterior.

Mesmo que todos os arquivos em um dispositivo iOS, incluindo aqueles sem uma classe de Proteção de dados explicitamente atribuída a eles, sejam armazenados em uma forma criptografada, especificando resultados NSFileProtectionNone na criptografia utilizando uma chave derivada unicamente baseada no UID do dispositivo. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos da NSFileProtectionNone devem ser estudados cautelosamente para determinar se uma proteção aprofundada com uma classe mais rigorosa de Proteção de dados é garantida.

Exemplo 1: Neste exemplo, o arquivo não está protegido (é acessível a qualquer momento em que o dispositivo estiver ligado):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...

Exemplo 2: Neste exemplo, os dados não estão protegidos (são acessíveis a qualquer momento em que o dispositivo estiver ligado):

...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionNone error:&err];
...

As constantes de acessibilidade do conjunto de chaves são projetadas para permitir que os aplicativos declarem quando os itens no conjunto de chaves devem estar acessíveis. Ao especificar uma das constantes de acessibilidade de um determinado item de conjunto de chaves, um desenvolvedor pode instruir o sistema de arquivos subjacente para criptografá-lo usando uma chave derivada do UID do dispositivo e da senha do usuário ou usando uma chave baseada exclusivamente no UID do dispositivo (bem como ao descriptografá-lo automaticamente).

As constantes de acessibilidade do conjunto de chaves devem ser atribuídas como o valor da chave kSecAttrAccessible no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:

-kSecAttrAccessibleAfterFirstUnlock:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Mesmo que todos os arquivos em um dispositivo iOS, incluindo aqueles sem uma constante de acessibilidade de conjunto de chaves, explicitamente atribuída, sejam armazenados em uma forma criptografada, especificar kSecAttrAccessibleAlways resulta no uso de uma chave derivada unicamente baseada no UID do dispositivo pela criptografia. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos de kSecAttrAccessibleAlways deverão ser estudados cautelosamente para determinar se uma proteção aprofundada com um nível de acessibilidade de conjunto de chaves mais rigoroso é garantida.

Exemplo 1: Neste exemplo, o arquivo não está protegido (é acessível a qualquer momento em que o dispositivo estiver ligado):

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...