Leitores como você ajudam a apoiar o MUO. Quando você faz uma compra usando links em nosso site, podemos ganhar uma comissão de afiliado.
Quando você deseja visitar um site, o navegador de internet que você usa recebe alguns dados desse site. Como resultado, ocorre um diálogo entre seu dispositivo e o site. Isso acontece com o protocolo chamado HTTP. É possível tomar algumas medidas de segurança adicionais intervindo neste diálogo.
Se você estiver administrando um site ou almejando uma carreira como desenvolvedor da Web, os cabeçalhos de segurança HTTP são inestimáveis para você, pois desempenham um papel ativo na segurança do usuário e do site.
O que é HTTP Strict-Transport-Security (HSTS)?
O HTTP Strict Transport Security (HSTS) força os usuários a usar HTTPS para cada solicitação feita em seu navegador. Essa é uma maneira sólida de combater ataques cibernéticos como downgrades e garantir a segurança de todo o tráfego.
Ativar o HSTS é muito fácil. Considere o diálogo entre o cliente e o servidor. Quando você tenta acessar um site pelo navegador, você é o cliente. O site que você deseja abrir depende do servidor. Seu objetivo é dizer ao servidor: "Quero abrir este site". Esta é uma operação de solicitação. O servidor, por outro lado, direciona você para o site se você atender às condições desejadas.
Lembre-se disso em relação a este exemplo de sinalizador de cabeçalho HTTP:
Strict-Transport-Security: max-age=16070200;
Quando você adiciona esse sinalizador às informações do cabeçalho da resposta HTTP, todas as solicitações geradas pelo usuário se tornam HTTPS. O que quer que o usuário escreva aqui, o navegador avaliará automaticamente o protocolo como HTTPS e estabelecerá uma conexão segura.
Como usar o HSTS
Em vez de adicionar todas essas informações de cabeçalho HTTP na camada de código, você pode fazer isso no Apache, IIS, Nginx, Tomcat e outros aplicativos de servidor da Web.
Para ativar o HSTS no Apache:
LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
Cabeçalho sempre definirEstrito-Transporte-Segurança "idade máxima=2592000; incluirSubDomínios"
</VirtualHost>
Para ativar o HSTS no Nginx:
add_header Strict-Transport-Security max-age=2592000; incluirsubdomínios
Para habilitar o HSTS com IIS web.config:
<system.webServer>
<httpProtocolo>
<CustomHeaders>
<adicionar nome ="Segurança Estrita de Transporte" valor="idade máxima=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Para usuários Cloudflare
A Cloudflare fornece serviço HTTPS gratuito para todos com seu serviço Keyless SSL; antes de solicitar o pré-carregamento do HSTS, você deve saber que seu certificado não pertence a você. Muitos sites usam certificados SSL porque são uma maneira simples de manter os dados seguros.
No entanto, Cloudflare agora suporta o recurso HSTS. Você pode ativar todos os recursos do HSTS, incluindo o pré-carregamento, por meio da interface da web Cloudflare sem se preocupar com as configurações no servidor da web.
O que é X-Frame-Options?
X-Frame-Options é um cabeçalho de segurança suportado por todos os navegadores modernos. X-Frame-Options visa proteger contra roubo de cliques, como Clickjacking. Como o nome sugere, trata-se do funcionamento de um quadro inline vulnerável, também conhecido como iframe. Esses são elementos em um site que incorporam outra página HTML no site "pai", para que você possa usar o conteúdo de outras fontes em seu site. Mas os invasores usam iframes sob seu próprio controle para fazer os usuários realizarem ações que não desejam.
Por esse motivo, você precisa impedir que invasores encontrem iframes no site.
Onde e como usar X-Frame-Options?
O que X-Frame-Options faz, alguns desenvolvedores tentam fazer com linguagens como JavaScript. Isso não está totalmente errado. No entanto, ainda existe um risco porque os códigos escritos em muitos aspectos não são suficientes. Portanto, seria sensato deixar essa tarefa para o navegador da Internet que você está usando.
No entanto, como desenvolvedor, existem três parâmetros para saber sobre X-Frame-Options:
- Negar: impede completamente que a página seja chamada em qualquer iframe.
- MESMA ORIGEM: evite que qualquer domínio que não seja o seu chame dentro do iframe.
- ALLOW-FROM uri: aceita chamadas de iframe de URI fornecidas como parâmetro. Bloqueie os outros.
Aqui o MESMA ORIGEM recurso se destaca mais. Porque, embora você possa chamar aplicativos em seus diferentes subdomínios com iframes uns dentro dos outros, você pode impedir que eles sejam chamados no domínio sob o controle do invasor.
Aqui estão exemplos de como você pode usar SAMEORIGIN e X-Frame-Options com NGINX, Apache e IIS:
Usando X-Frame-Options SAMEORIGIN para Nginx:
add_header X-Frame-Options SAMEORIGIN;
Usando X-Frame-Options SAMEORIGIN para Apache:
Cabeçalho sempre anexa X-Frame-Options SAMEORIGIN
Usando X-Frame-Options SAMEORIGIN para IIS:
<httpProtocolo>
<CustomHeaders>
<adicionar nome ="X-Frame-Options" valor="MESMA ORIGEM" />
</customHeaders>
</httpProtocol>
Basta adicionar apenas o cabeçalho SAMEORIGIN para proporcionar maior segurança aos seus visitantes.
O que é proteção X-XSS?
O uso de informações de cabeçalho X-XSS-Protection pode proteger os usuários contra ataques XSS. Em primeiro lugar, você precisa eliminar vulnerabilidades XSS no lado do aplicativo. Depois de fornecer segurança baseada em código, outras medidas, ou seja, cabeçalhos X-XSS-Protection, são necessárias contra vulnerabilidades XSS em navegadores.
Como usar a proteção X-XSS
Os navegadores modernos podem detectar potenciais cargas XSS filtrando o conteúdo gerado pelo aplicativo. É possível ativar esse recurso com as informações do cabeçalho X-XSS-Protection.
Para ativar o cabeçalho X-XSS-Protection no Nginx:
add_header X-Frame-X-XSS-Proteção 1;
Para ativar o cabeçalho X-XSS-Protection no Apache:
O cabeçalho sempre anexa X-XSS-Protection 1
Para habilitar o cabeçalho X-XSS-Protection no IIS:
<httpProtocolo>
<CustomHeaders>
<adicionar nome ="X-XSS-Proteção" valor="1" />
</customHeaders>
</httpProtocol>
Para evitar que o bloco de código com ataque XSS por padrão seja executado, você pode usar algo assim:
X-XSS-Proteção: 1; modo=bloco
Essa pequena alteração precisa ser feita se houver uma situação potencialmente perigosa e você quiser impedir que todo o conteúdo seja renderizado.
O que é X-Content-Type-Options?
Os navegadores realizam uma análise chamada MIME Type Sniffing no conteúdo apresentado a eles pelo aplicativo da web. Por exemplo, se houver uma solicitação de acesso a um arquivo PDF ou PNG, os navegadores que realizam análises na resposta HTTP inferem o tipo de arquivo.
Considere um arquivo com extensão jpeg, mas que na verdade possui conteúdo de texto/HTML. Depois de usar as extensões e passar as proteções no módulo de upload, o arquivo é carregado com sucesso. O arquivo carregado é chamado por meio do URL e o sniffing do tipo MIME retorna Texto/HTML como resultado. Ele renderiza o conteúdo como HTML. É quando ocorre a vulnerabilidade XSS.
Portanto, você precisa impedir que os navegadores decidam o conteúdo por detecção de tipo MIME. Para fazer isso, você pode usar nosniff.
Cabeçalho X-Content-Type-Options para Nginx:
add_header X-Content-Type-Options nosniff;
Cabeçalho X-Content-Type-Options para Apache:
Cabeçalho sempre X-Content-Type-Options nosniff
Cabeçalho X-Content-Type-Options para IIS:
<httpProtocolo>
<CustomHeaders>
<adicionar nome ="X-Content-Type-Options" valor="não cheirar" />
</customHeaders>
</httpProtocol>
O que é o sinalizador de cookie HttpOnly?
Os aplicativos da Web rastreiam as sessões dos usuários por meio do ID da sessão. Os navegadores irão armazenar isso e adicioná-lo automaticamente a cada solicitação HTTP dentro do escopo do cookie.
É possível usar cookies para fins diferente da transferência da chave de sessão, no entanto. Os hackers podem descobrir os dados do usuário usando a vulnerabilidade XSS mencionada acima ou por meio de um ataque Cross-Site Request Forgery (CSRF). Então, quais cookies são mais importantes em termos de segurança?
Você pode considerar como exemplo as informações contidas na última imagem em que você clicou na galeria de imagens. Desta forma, o tráfego HTTP é menor e uma parte da carga pode ser resolvida pelo navegador de internet do usuário com scripts do lado do cliente.
Isso e onde HttpOnly entra. Segue abaixo um exemplo de como deve ser a atribuição do cookie:
Definir-Biscoito: do utilizador=t=cdabe8a1c2153d726; caminho=/; HttpOnly
Observe o valor HttpOnly enviado no Set-Cookie Operação. O navegador verá isso e não processará valores com o sinalizador HttpOnly quando o cookie for acessado por meio do documento.cookie variável. Outro sinalizador usado no processo Set-Cookie é o sinalizador Secure. Isso indica que o valor do cookie será adicionado ao cabeçalho apenas para solicitações HTTPS. Os sites de comércio eletrônico geralmente o usam porque desejam reduzir o tráfego de rede e aumentar o desempenho.
Usando esse método, você pode ocultar dados críticos dos usuários, como nomes de usuário, senhas e informações de cartão de crédito. Mas há um problema. Os usuários que concluírem o processo de login recebem um valor de cookie sem o sinalizador Secure. O usuário pode ter a chave de sessão ao fazer uma solicitação HTTP para links não HTTPS. Adicionar o sinalizador seguro é fácil:
Definir-Biscoito: do utilizador=t=cdabe8a1c2153d726; caminho=/; Seguro
Quando você não deve usar o HttpOnly? Se você depende do Javascript, deve ser cauteloso, pois isso pode tornar seu site menos seguro.
Pequenos passos funcionam para uma segurança na Web mais ampla
Você não precisa de software avançado e conhecimento de servidor para aumentar a segurança dos aplicativos da web. Ao alterar apenas algumas linhas, você pode evitar alguns ataques sérios. Claro, isso não é suficiente. No entanto, é um passo pequeno, mas eficaz para a segurança do site. O conhecimento é o melhor preventivo, por isso também é útil conhecer as nuances sutis de como o HTTPS protege os dados durante a transferência.
