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);
  }
  ...
}

Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. Um campo não final viola a imutabilidade da classe permitindo que o valor seja alterado.

Exemplo 1: O código a seguir para uma classe final imutável declara erroneamente um campo public e não final.

@Immutable
public class ImmutableInteger {
public int value;

}

Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. Um campo público de um tipo mutável permite que o código externo à classe modifique o conteúdo e viole a imutabilidade da classe.

Exemplo 1: O código a seguir para uma classe final imutável declara erroneamente um Set public e final.

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

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.

Erros de otimização do compilador ocorrem quando:

1. Dados secretos são armazenados na memória.

2. Os dados secretos são limpos da memória por meio da substituição de seu conteúdo.



3. O código-fonte é compilado com o uso de um compilador de otimização, que identifica e remove a função que substitui o conteúdo como um repositório morto porque a memória não é usada posteriormente.
Exemplo 1: O código a seguir lê uma senha do usuário, utiliza-a para se conectar a um mainframe back-end e depois tenta limpar a senha da memória usando memset().

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

O código no exemplo comporta-se de forma correta quando executado literalmente, mas, se ele for compilado com o uso de um compilador de otimização, como o Microsoft Visual C++(R) .NET ou o GCC 3.x, a chamada para memset() será removida como um repositório morto porque o buffer pwd não é usado após a substituição de seu valor [2]. Como o buffer pwd contém um valor sensível, o aplicativo poderá ficar vulnerável a ataques se os dados permanecerem residentes na memória. Se os invasores puderem acessar a região correta da memória, eles poderão usar a senha recuperada para ganhar o controle do sistema.

É uma prática comum substituir dados sensíveis manipulados na memória, como senhas ou chaves criptográficas, a fim de impedir que os invasores descubram segredos do sistema. No entanto, com o advento de compiladores de otimização, os programas nem sempre se comportam como seu código-fonte sozinho poderia sugerir. No exemplo, o compilador interpreta a chamada para memset() como um código morto, pois a memória que está sendo gravada não é utilizada depois, apesar do fato de existir claramente uma motivação de segurança para que essa operação ocorra. O problema aqui é que muitos compiladores e, na verdade, muitas linguagens de programação, não consideram esta e outras preocupações de segurança em seus esforços para melhorar a eficiência.

Em geral, os invasores exploram esse tipo de vulnerabilidade usando um despejo de memória ou um mecanismo de tempo de execução para acessar a memória usada por um aplicativo específico e recuperar as informações secretas. Depois que um invasor tem acesso às informações secretas, é relativamente simples e direto explorar ainda mais o sistema e possivelmente comprometer outros recursos com os quais o aplicativo interage.

Se uma verificação de limites de array envolver o cálculo de um ponteiro ilegal e, em seguida, a determinação de que esse ponteiro está fora dos limites, alguns compiladores otimizarão a verificação, supondo que o programador nunca criaria intencionalmente um ponteiro ilegal.

Exemplo 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

A operação buf + len é maior que 2^32 e, portanto, o valor resultante é menor que buf. Porém, como um estouro aritmético em um ponteiro é um comportamento indefinido, alguns compiladores assumirão buf + len >= buf e otimizarão a verificação de quebra de linha. Como resultado dessa otimização, o código após esse bloco pode ser vulnerável a um buffer overflow.

O aplicativo Django expõe a visualização serve do aplicativo static files, o qual não foi projetado para ser implantado em um ambiente de produção. De acordo com a documentação do Django:

"As ferramentas static files, em sua maioria, são projetadas para ajudar a fazer com que arquivos estáticos sejam implantados com êxito na produção. Isso geralmente significa um servidor de arquivos estáticos separado e dedicado, o que é bastante sobrecarga quando se refere ao desenvolvimento local. Portanto, o aplicativo staticfiles entrega com uma visualização de auxílio rápida e suja que você pode utilizar para servir arquivos localmente durante o desenvolvimento.

Essa visualização funcionará somente se DEBUG for True.

Isso porque essa visualização é extremamente ineficiente e provavelmente insegura. Isso destina-se apenas ao desenvolvimento local, e nunca deve ser usado na produção."

Os recursos de aplicativos que contenham informações confidenciais ou que ofereçam funcionalidades privilegiadas, geralmente estarão em um risco maior de exploração. Durante a fase de reconhecimento, um invasor farpa tentativas para descobrir esses arquivos e diretórios. Usar esquemas de nomeação previsíveis para tais recursos torna mais fácil para o invasor localizá-los. Todos os recursos de aplicativos que lidam com funcionalidades confidenciais, como autenticação, tarefas administrativas, ou gerenciamento de informações privadas, devem ser suficientemente protegidos contra a descoberta.

Exemplo 1: Neste exemplo, o aplicativo admin é implantado em uma URL previsível:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Os recursos responsáveis pelo armazenamento de dados devem ser separados daqueles que implementam a funcionalidade do aplicativo. Os programadores devem ter cautela ao criar recursos temporários ou de backup.