.
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 o 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 web, os cabeçalhos de segurança HTTP são inestimáveis para você, porque 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 que fazem 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 através do seu 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 de cabeçalho da resposta HTTP, todas as solicitações geradas pelo usuário se tornarão 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 HST
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 web.
Para habilitar o HSTS no Apache:
LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains"
</VirtualHost>
Para habilitar o HSTS no Nginx:
add_header Strict-Transport-Security max-age=2592000; includeSubdomains
Para habilitar o HSTS com o IIS web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Para usuários da Cloudflare
A Cloudflare oferece 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, a Cloudflare agora oferece suporte ao recurso HSTS. Você pode ativar todos os recursos do HSTS, incluindo pré-carregamento, por meio da interface web da Cloudflare sem problemas com as configurações no servidor 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 frame 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 conteúdo de outras fontes em seu site. Mas os invasores usam iframes sob seu próprio controle para fazer com que os usuários realizem ações que não desejam.
Por esse motivo, você precisa impedir que invasores encontrem iframes no site.
Onde e como usar as opções do X-Frame?
O que o 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.
- SAMEORIGEM: impede 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 outros.
Aqui o SAMEORIGEM recurso se destaca mais. Porque embora você possa chamar aplicativos em seus diferentes subdomínios com iframes entre si, você pode impedir que eles sejam chamados no domínio sob o controle do invasor.
Aqui estão alguns 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:
Header always append X-Frame-Options SAMEORIGIN
Usando X-Frame-Options SAMEORIGIN para IIS:
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
A simples adição do cabeçalho SAMEORIGIN proporcionará maior segurança para 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 as 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 possíveis 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 habilitar o cabeçalho X-XSS-Protection no Nginx:
add_header X-Frame-X-XSS-Protection 1;
Para habilitar o cabeçalho X-XSS-Protection no Apache:
Header always append X-XSS-Protection 1
Para habilitar o cabeçalho X-XSS-Protection no IIS:
<httpProtocol>
<customHeaders>
<add name="X-XSS-Protection" value="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-Protection: 1; mode=block
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 arquivo PNG, os navegadores que realizam a análise da resposta HTTP inferem o tipo de arquivo.
Considere um arquivo com uma extensão jpeg, mas que na verdade tenha 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 a detecção de 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 sobre o conteúdo pelo sniffing do 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:
Header always X-Content-Type-Options nosniff
Cabeçalho X-Content-Type-Options para IIS:
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
</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.
No entanto, é possível usar cookies para outros fins que não a transferência da chave de sessão. Os hackers podem descobrir 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 as informações contidas na última imagem em que clicou na galeria de imagens como exemplo. Dessa 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 Somente Http vem. Abaixo está um exemplo de como a atribuição de cookies deve ser:
Set-Cookie: user=t=cdabe8a1c2153d726; path=/; 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 costumam usá-lo 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 concluem o processo de login recebem um valor de cookie sem o sinalizador Seguro. O usuário pode ter a chave de sessão quando fizer uma solicitação HTTP para links não HTTPS. Adicionar o sinalizador seguro é fácil:
Set-Cookie: user=t=cdabe8a1c2153d726; path=/; Secure
Quando você não deve usar HttpOnly? Se você confia em Javascript, deve ter cuidado, 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. Alterando 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 é a melhor prevenção, por isso também é útil conhecer as nuances sutis de como o HTTPS protege os dados durante a transferência.
.
