Os formulários de login precisam de tokens contra ataques CSRF?

161

Pelo que aprendi até agora, o objetivo dos tokens é impedir que um invasor forje um envio de formulário.

Por exemplo, se um site tiver um formulário que insira itens adicionados ao seu carrinho de compras, e um invasor poderá enviar spam ao seu carrinho de compras com itens que você não deseja.

Isso faz sentido, pois pode haver várias entradas válidas para o formulário do carrinho de compras, tudo o que o invasor precisa fazer é conhecer um item que o site está vendendo.

Entendo como os tokens funcionam e adiciono segurança neste caso, porque eles garantem que o usuário realmente preencheu e pressionou o botão "Enviar" do formulário para cada item adicionado ao carrinho.

No entanto, os tokens adicionam segurança a um formulário de login do usuário, o que requer um nome de usuário e senha?

Como o nome de usuário e a senha são muito exclusivos, o invasor precisará conhecer ambos para que a falsificação de login funcione (mesmo que você não tenha a configuração de tokens) e, se um invasor já souber disso, poderá acessar o site. ele mesmo. Sem mencionar, um ataque de CSRF que faça o usuário se autenticar não teria nenhum propósito prático de qualquer maneira.

Meu entendimento dos ataques e tokens de CSRF está correto? E eles são inúteis para os formulários de login do usuário, como suspeito?

php token csrf php_learner
fonte
Eles podem seqüestrar seu roteador, porque você provavelmente usa uma senha padrão e não é protegido por CSRF para login.
AbiusX
Sim, outros sites não podem imitar seu formulário de login. O que eles podem conseguir fazendo isso? Primeiro você não quer permitir isso. Segundo: casos de falha muito fáceis, como bloquear o usuário devido a senha incorreta n não. vezes, pode ser evitado.
precisa saber é o seguinte

Respostas:

126

Sim. Em geral, você precisa proteger seus formulários de login dos ataques CSRF, como qualquer outro.

Caso contrário, seu site estará vulnerável a uma espécie de ataque de "phishing de domínio confiável". Em resumo, uma página de login vulnerável ao CSRF permite que um invasor compartilhe uma conta de usuário com a vítima.

A vulnerabilidade ocorre assim:

  1. O invasor cria uma conta de host no domínio confiável
  2. O invasor falsifica uma solicitação de login no navegador da vítima com as credenciais dessa conta de host
  3. O invasor induz a vítima a usar o site confiável, onde elas podem não perceber que estão logadas pela conta do host
  4. O invasor agora tem acesso a quaisquer dados ou metadados que a vítima "criou" (intencionalmente ou não) enquanto o navegador estava conectado à conta do host

Como um exemplo pertinente, considere o YouTube . O YouTube permitiu que os usuários vissem um registro do "próprio" histórico de visualizações, e seu formulário de login era vulnerável a CSRF! Assim, como resultado, um invasor pode configurar uma conta com uma senha que eles conhecem, fazer o login da vítima no YouTube usando essa conta - perseguindo os vídeos que a vítima estava assistindo.

Há alguma discussão neste tópico de comentário que implica que "somente" poderia ser usado para violações de privacidade como essa. Talvez, mas para citar a seção no artigo da Wikipedia sobre CSRF :

O Login CSRF possibilita vários ataques novos; por exemplo, um invasor pode posteriormente fazer login no site com suas credenciais legítimas e visualizar informações privadas, como histórico de atividades que foram salvas na conta.

Ênfase em "novos ataques". Imagine o impacto de um ataque de phishing contra seus usuários e, em seguida, imagine o referido ataque de phishing trabalhando através do marcador de confiança do usuário em seu site! O artigo vinculado no tópico de comentários acima mencionado fornece vários exemplos que vão além de simples ataques de privacidade.

natevw
fonte
6
Como a proteção CSRF ajuda? Existe algo impedindo o invasor de solicitar seu próprio token CSRF e apenas enviá-lo? Como não existe sessão autenticada, não há razão para o servidor da Web preferir um token ao outro.
A. Wilson
2
"Existe algo impedindo o invasor de pedir seu próprio token CSRF e apenas enviá-lo?" - Sim! Essa é a suposição por trás da lógica de prevenção da CSRF. Os navegadores permitiram / enviam um formulário para atingir outra origem, mas eles nunca [intencionalmente] permitiram que JS lesse dados entre sites, exceto agora via opt-in CORS. A menos que você configure o CORS errado, o invasor pode acionar o envio de um formulário (que pode incluir um token CSRF existente nos cookies ), mas não tem como saber se o token envia a segunda cópia necessária (por exemplo, no corpo / cabeçalhos). Portanto, o código CSRF será rejeitado.
Natevw
7
Acho que seu último comentário está errado (você entendeu mal o que A. Wilson estava dizendo). Estamos dizendo que um invasor pode carregar http://good.com/login.htmlum cliente, analisar o token CSRF aninhado e depois publicar http://bad.com/login.htmlque contém um formulário modificado que envia seu nome de usuário, senha e token, independentemente do que a vítima digita. O CORS não se aplica porque você ' Temos dois clientes separados: o atacante e a vítima. Então, para reiterar a pergunta: a proteção CSRF realmente funciona para formulários de login?
Gili
8
Sim, o CSRF protegerá um formulário de login contra falsificação de solicitação entre sites . Um token CSRF adequado é criptograficamente exclusivo cada vez que é gerado. Claro, o atacante pode obter uma token , mas ainda NÃO VAI CORRESPONDER AO cookie [potencialmente não definido ] que a vítima possui no navegador, e o invasor não tem como definir o cookie sem comprometer uma página no bom domínio. (O seu exemplo parece um pouco confuso entre CSRF e algum tipo de ataque phishing estranho, embora, então eu não tenho certeza se eu estou respondendo a sua pergunta real ...)
natevw
3
Posso estar errado, mas parece haver uma ameaça significativa se o usuário acidentalmente fizer algo relacionado à compra de itens. Por exemplo, um invasor engana o usuário para fazer login em um site, e o usuário continua a comprar itens sem perceber que está em outra conta (pense na Amazon ou similar). Agora o invasor tem acesso às informações salvas de pagamento, pode redirecionar as compras etc.
you786
14

Seu entendimento está correto - o ponto principal do CSRF é que o invasor pode forjar uma solicitação de aparência legítima de antemão. Mas isso não pode ser feito com um formulário de login, a menos que o invasor saiba o nome de usuário e a senha da vítima; nesse caso, existem maneiras mais eficientes de atacar (faça o login).

Em última análise, a única coisa que um invasor pode fazer é incomodar seus usuários ao enviar spam para logins com falha, quando o sistema de segurança pode bloquear o usuário por um período de tempo.

Jon
fonte
2
Nossa resposta super rápida! Muito obrigado! Agora posso continuar construindo meu site com confiança.
Php_learner
21
O CSRF de login ainda pode ser usado para ataques à privacidade do usuário seclab.stanford.edu/websec/csrf/csrf.pdf
squiddle
6
@ Quebra-cabeça: Esse é um artigo bastante interessante, obrigado pelo link. Mas depende do logon do usuário com uma conta sob o controle do atacante e assume que o usuário não perceberá que algo não está certo e assume que o usuário produzirá informações confidenciais que serão armazenadas no servidor. Então, IMHO é bem menos sério que o CSRF "clássico".
29412 Jon
6
@ Jon Sim, pode ser menos grave, mas no final pode ser mais do que apenas inconveniente, a saber, invasão de privacidade. Todo serviço precisa definir seu modelo de ameaça e lidar com isso de acordo. Para fazer isso, você precisa pelo menos estar ciente das possíveis ameaças. É por isso que eu adicionei meus 2 centavos.
squiddle 29/08/12
1
Por favor, você poderia expandir como eles "Em última análise, a única coisa que um invasor pode fazer é incomodar seus usuários ao enviar spam para logins com falha, quando o sistema de segurança pode bloquear o usuário por um período de tempo".
precisa
0

Sim , outros sites não podem imitar seu formulário de login! Tão simples como isso.

O que eles podem conseguir fazendo isso?

  • Primeiro: você não quer permitir isso.
  • Segundo: até casos de falha muito simples, como:
    • bloqueio de usuário devido a senha incorreta nno. vezes, pode ser evitado.
    • Alertas de hackers Flase podem ser evitados. etc etc.
mayankcpdixit
fonte
A maioria desses pontos está incorreta. O atacante pode criar um formulário de logon, obter credenciais do usuário para carregar o formulário de logon (com token csrf) e postar as três informações no destino. O CSRF não impede isso.
Snapey 13/05/19
Os navegadores @Snapey geralmente não permitem que o JS leia dados CSRF. Usando JS, você não pode imitar a solicitação de envio de formulário genuína.
Mayankcpdixit
O token csrf é frequentemente transmitido ao cliente para uso por javascript. Não estou falando de cors que estou falando sobre o invasor, apenas solicitando o formulário de login e preenchendo credenciais. @mayankcpdxit. Você parece sugerir que o csrf impede o preenchimento de credenciais, o que não impede.
Snapey
Teoricamente, sim, não pode impedir. Mas não é possível automatizar o preenchimento de credenciais após o CSRF se você parar de carregar formulários CSRF em iframes e parar de permitir solicitações de origem cruzada.
Mayankcpdixit 08/07/19
-1

Pré-login de validação de CSRF não faz muito sentido IMHO.

Graças a @squiddle pelo link: seclab.stanford.edu/websec/csrf/csrf.pdf , podemos ler na primeira página:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Se você tentar o pré-login da validação do CSRF, poderá dar a um invasor em potencial a oportunidade de raspar um código válido do seu site! Ele / ela seria capaz de postar novamente o token derrotando o objetivo.

Talvez um invasor possa tentar adivinhar o nome de usuário do seu site. O que eu fiz, se o endereço IP tentar adivinhar, digamos, 10 nomes de usuários sem sucesso, eu simplesmente o incluo na lista negra.

Patrice Gagnon
fonte