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.

X-XSS-Protection é um cabeçalho HTTP introduzido pela Microsoft e, desde então, adotado por outros navegadores. Ele se destinava a ajudar a impedir que ataques de Cross-Site Scripting sejam bem sucedidos, mas, inadvertidamente, levou a uma vulnerabilidade que tornava vulneráveis sites seguros[1]. Por isso, isso não deve ser utilizado em versões mais antigas do Internet Explorer e deve ser desabilitado mediante a definição do cabeçalho como 0.

Exemplo 1: O seguinte configura incorretamente o middleware Helmet em um aplicativo Express para ativar isso em todas as versões do Internet Explorer:

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

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 1:

  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 1: 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 1: O código a seguir 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 1: 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.

Um dos novos recursos do HTML5 é enviar mensagens entre documentos. O recurso permite que os scripts publiquem mensagens em outras janelas. A API correspondente permite ao usuário especificar a origem da janela de destino. No entanto, deve-se ter cautela ao especificar a origem pretendida porque caso ela seja excessivamente permissiva, permitirá que um script malicioso se comunique com a janela da vítima de forma inadequada, levando à falsificação, ao roubo de dados, a ataques de retransmissão e outros.

Exemplo 1: O exemplo a seguir usa um curinga para especificar programaticamente a origem pretendida da mensagem a ser enviada.

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

Usar o * como o valor da origem pretendida indica que o script está enviando uma mensagem a uma janela, independentemente da respectiva origem.

Os navegadores não enviam o cabeçalho do referenciador por padrão com solicitações originadas de HTTPS para links HTTP não criptografados. No entanto, quando um destino de solicitação também é HTTPS, o cabeçalho é enviado independentemente da origem. Um desenvolvedor pode deixar informações confidenciais em URLs, que são expostas a sites de terceiros por meio do cabeçalho do referenciador. O cabeçalho Referrer-Policy é introduzido para controlar o comportamento do navegador em relação ao cabeçalho do referenciador. A opção Unsafe-URL remove todas as restrições e envia o cabeçalho do referenciador com cada solicitação.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a política de referenciador segura padrão:

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

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 cabeçalho Content-Security-Policy-Report-Only fornece a autores e administradores de aplicativos Web a capacidade de monitorar políticas de segurança, em vez de impô-las. Esse cabeçalho geralmente é usado ao serem experimentadas e/ou desenvolvidas políticas de segurança para um site. Quando uma política é considerada efetiva, você pode impô-la usando o campo de cabeçalho Content-Security-Policy.

Exemplo 1: O seguinte código define uma Política de Segurança de Conteúdo no modo Report-Only:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.example.com/login.php?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.

    ...
    String lang = request.getParameter("lang");
    GetMethod get = new GetMethod("http://www.example.com");
    get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
    get.execute();
    ...

URL: http://www.example.com?poll_id=4567
Link1: <a href="001">Inglês<a>
Link2: <a href="002">Espanhol<a>

O programador não considerou a possibilidade de que um invasor pudesse fornecer um lang como en&poll_id=1 e, em seguida, fosse capaz de alterar poll_id à vontade.

Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.



A maioria das implementações Java EE permite métodos HTTP que não estão explicitamente listados na configuração. Por exemplo, a seguinte restrição de segurança é aplicada ao método HTTP GET, mas não a outros verbos HTTP:

    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Uma vez que verbos como HEAD não são explicitamente definidos em uma tag <http-method> nessa configuração, pode ser possível exercer a funcionalidade administrativa substituindo as solicitações GET ou POST por solicitações HEAD. Para que as solicitações HEAD exerçam a funcionalidade administrativa, a condição 3 deve ser mantida - o aplicativo deve executar comandos baseados em verbos diferentes de POST. Alguns servidores web/de aplicativos aceitarão verbos HTTP não padrão arbitrários e responderão como se tivessem recebido uma solicitação GET. Se for esse o caso, um invasor poderá ver as páginas administrativas usando um verbo arbitrário em uma solicitação.

Por exemplo, uma solicitação GET típica do cliente se parece com:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

Em um ataque de adulteração de verbo HTTP, um invasor substituirá GET por algo como FOO

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.

As funções que procuram caracteres em um buffer podem retornar um ponteiro fora dos limites do buffer fornecido em qualquer uma das seguintes circunstâncias:

- Um usuário controla o conteúdo do buffer a ser pesquisado.

- Um usuário controla o valor a ser pesquisado.

Exemplo 1: O programa curto a seguir usa um argumento de linha de comando não confiável como o buffer de pesquisa em uma chamada para rawmemchr().

int main(int argc, char** argv) {
  char* ret = rawmemchr(argv[0], 'x');
  printf("%s\n", ret);
}

O objetivo do programa é imprimir uma substring de argv[0], mas ele pode acabar imprimindo alguma parte da memória localizada acima de argv[0].

Esse problema é semelhante a um erro de terminação de string no qual o programador depende de uma matriz de caracteres conter um terminador nulo.

Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. No entanto, um dos campos mutáveis da classe tinha um método mutante chamado nele fora do construtor e do destruidor.

Exemplo 1: O código a seguir para uma classe final imutável declara um Set private e final e, em seguida, cria erroneamente um método que transforma o Set.

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}