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("*");

Erros de controle de cluster Hadoop ocorrem quando:

- Os dados entram em um programa por uma fonte não confiável.

- Os dados são consumidos pelos componentes principais do cluster Hadoop, como NameNode, DataNode e JobTraker, para alterar o estado do cluster.

Clusters Hadoop são um ambiente hostil. Quando configurações de segurança de proteção do acesso não autorizado a nós de cluster não são definidas corretamente, um invasor pode ser capaz de assumir o controle da infraestrutura. Isso resulta na possibilidade de que todos os dados fornecidos pelo cluster Hadoop sejam adulterados.

Exemplo 1: O código a seguir mostra um envio de Job em um aplicativo de cliente típico que usa entradas da linha de comando na máquina mestre do cluster Hadoop:

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

Incluir conteúdo executável de outro site é uma proposta arriscada. Isso vincula a segurança do seu site à segurança do outro site.

Exemplo: Considere a seguinte tag script.

  <script src="http://www.example.com/js/fancyWidget.js"></script>

Se essa tag aparecer em um site diferente de www.example.com, esse site dependerá de www.example.com para apresentar o código correto e não mal-intencionado. Se os invasores puderem comprometer www.example.com, eles poderão alterar o conteúdo de fancyWidget.js para corromper a segurança do site. Por exemplo, eles poderiam adicionar código a fancyWidget.js para roubar dados confidenciais de um usuário.

As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função realloc() costuma ser usada para aumentar o tamanho de um bloco de memória alocada. Muitas vezes, essa operação requer a cópia do conteúdo do bloco de memória antigo em um bloco novo e maior. Essa operação deixa o conteúdo do bloco original intacto, mas inacessível ao programa, impedindo que ele consiga limpar dados confidenciais da memória. Se mais tarde um invasor puder examinar o conteúdo de um despejo de memória, os dados confidenciais poderão ficar expostos.

Exemplo: O código a seguir chama realloc() em um buffer que contém dados confidenciais:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

Há uma tentativa de limpar os dados confidenciais da memória, mas, como realloc() é usado, uma cópia dos dados ainda pode ser exposta na memória originalmente alocada para plaintext_buffer.

As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função VirtualLock destina-se a bloquear páginas na memória para impedir que elas sejam paginadas no disco. No entanto, no Windows 95/98/ME, a função é implementada apenas como rascunho e não tem nenhum efeito.

Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo:

  Hidden hidden = new Hidden(element);

Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.

O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.

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

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

Uma das características do HTML5 é a capacidade de armazenar dados em um banco de dados SQL do lado do cliente. A principal informação necessária para iniciar a gravação e a leitura do banco de dados é o nome dele. Portanto, é crucial que o nome do banco de dados seja uma cadeia única diferente para cada usuário. Se o nome do banco de dados for fácil de adivinhar, terceiros não autorizados, como outros usuários, podem ser capazes de roubar dados confidenciais ou corromper as entradas do banco de dados.
Exemplo: Este código usa um nome de banco de dados fácil de adivinhar:

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

Este código será executado com sucesso, mas qualquer pessoa que possa adivinhar o nome do banco de dados como 'mydb' pode acessá-lo.

O HTML5 fornece uma nova habilidade de realizar uma validação simples de campos de formulário de entrada. É possível especificar se um campo de formulário de entrada é necessário com o uso do atributo required. Especificar o tipo de campo garante que a entrada seja verificada com relação ao seu tipo. É possível até mesmo fornecer um atributo pattern personalizável que verifica a entrada em relação a uma expressão regular. No entanto, essa validação é desabilitada com a adição de um atributo novalidate a uma tag de formulário e de um atributo formnovalidate a uma tag de entrada de envio.

Exemplo 1: O exemplo a seguir desabilita a validação de formulário por meio de um atributo novalidate.

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

Exemplo 2: O exemplo a seguir desabilita a validação de formulário por meio de um atributo formnovalidate.

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

Formulários HTML com validação desabilitada não são de fácil utilização e podem expor o servidor a vários tipos de ataques. Entradas não verificadas resultam são a causa raiz de vulnerabilidades, como criação de scripts entre sites, controle de processos e SQL Injection.

Tornou-se importante impor a privacidade dos dados de um determinado documento da Web devido à existência de explorações de canais laterais resultantes de vulnerabilidades como Spectre e Meltdown. A Política de Abertura de Origens Cruzadas (COOP) foi criada para ajudar a prevenir a exposição de informações confidenciais devido a ataques de canal lateral. Especificamente, o COOP pode impor o isolamento do grupo de contexto de navegação de um documento em relação a outros documentos externos, como pop-ups.

Exemplo 1: O código a seguir mostra uma configuração COOP insegura de "unsafe-none" na estrutura do Django. Isso pode permitir que um documento externo acesse os dados privados do grupo de contexto de navegação de um documento de origem devido a um ataque de canal lateral.

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

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

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

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

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

A Content Security Policy (CSP) é um cabeçalho de segurança declarativa que permite que os desenvolvedores estipulem de quais domínios o site tem permissão para fazer o upload de conteúdo ou para iniciar conexões durante a renderização no navegador da web. Isso fornece uma camada adicional de segurança contra vulnerabilidades críticas, como criação de script entre sites, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a criação de uma lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer essa camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos, a saber: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Cada uma delas tem uma lista de fontes uma vez que permite-se a um valor que especifica domínios do site acessar um recurso abrangido por esta diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade ou parte da fonte. Nenhuma das diretrizes é obrigatória. Os navegadores autorizarão todas as fontes de uma diretiva não listada ou derivarão o valor delas a partir da diretiva default-src opcional. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Os dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Considere as seguintes situações de configuração incorreta:

- As diretivas com unsafe-inline ou unsafe-eval torna o objetivo da CSP inútil.
- A diretiva script-src é definida mas nenhum script nonce é configurado.
- A diretiva frame-src é definida mas nenhum script sandbox é configurado.
- Várias instâncias desse cabeçalho são permitidas na mesma resposta. A equipe de desenvolvimento e a equipe de segurança podem definir um cabeçalho, mas pode-se usar um dos nomes obsoletos. Enquanto os cabeçalhos obsoletos são liquidados se um cabeçalho com o nome mais recente (ou seja, a Content Security Policy) não estiverem presentes, eles são ignorados se uma política com o nome de conteúdo de segurança de cabeçalho estiver presente. As versões mais antigas só compreendem nomes obsoletos, portanto, a fim de conquistar o apoio desejado, é essencial que a resposta inclua uma política idêntica com todos os três nomes.
- Se uma diretiva for repetida dentro da mesma instância do cabeçalho, todas as ocorrências subsequentes serão ignoradas.

Exemplo 1: Esta configuração django-csp utiliza unsafe-inline e unsafe-eval diretivas inseguras para permitir scripts embutidos e avaliação de código:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código.

O Spring Security e outras estruturas não adicionam cabeçalhos da Política de Segurança de Conteúdo por padrão. O autor do aplicativo Web deve declarar as políticas de segurança a serem impostas ou monitoradas para que os recursos protegidos se beneficiem dessa camada adicional de segurança.

Se você permitir que seu site seja adicionado a um quadro, isso poderá acarretar um problema de segurança. Por exemplo, isso pode levar a vulnerabilidades de clickjacking ou permitir comunicações indesejadas entre quadros.

Por padrão, estruturas como o Spring Security incluem o cabeçalho X-Frame-Options para indicar ao navegador se o aplicativo deve ser enquadrado. Se você desabilitar ou não definir esse cabeçalho, isso poderá levar a vulnerabilidades entre quadros.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar o cabeçalho X-Frame-Options:

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

A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativo que permite que os desenvolvedores especifiquem o comportamento permitido relacionado à segurança no navegador, incluindo uma lista de permissões locais dos quais o conteúdo pode ser recuperado. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer esta camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline' e 'unsafe-eval', fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Exemplo 1: O seguinte código define uma diretiva default-src excessivamente flexível e insegura:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin está definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja 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.

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

Usar * como o valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo podem ser acessados pelo JavaScript em execução em qualquer domínio.