não é CSRF um problema de segurança do navegador?

Question

Em relação cross-site request forgery (CSRF) ataques, se os cookies são método de autenticação mais utilizado, porque é que os navegadores web permitem o envio de biscoitos de algum domínio (e a esse domínio) de uma página gerada a partir de outro domínio?

Não é CSRF facilmente evitável no navegador, não permitindo tal comportamento?

Tanto quanto eu sei, esse tipo de verificação de segurança é não implementado em navegadores web, mas eu não entendo o porquê. Será que eu conseguir alguma coisa de errado?

Sobre CSRF:

• na Wikipedia
• No Coding Horror

Edit: Eu acho que os cookies não devem ser enviados em http POST no caso acima. Esse é o comportamento do navegador que me surpreende.

Answer 1

Por que não os cookies do navegador de envio?

Site A ( http://www.sitea.com ) define um cookie para o usuário.

navega usuário para o site B ( http://www.siteb.com ). Site B possui integração com o site A - clique aqui para fazer algo no local A! Os usuários cliques "aqui".

Quanto ao navegador pode dizer, o usuário está fazendo uma decisão consciente de fazer um pedido para o site A, por isso manipula-lo da mesma forma que iria lidar com qualquer pedido para o site A, e que inclui o envio de biscoitos local A de o pedido para o site a.

---

Editar : Eu acho que a questão principal aqui é que você acha que há uma distinção entre os cookies de autenticação e outros cookies. Os cookies podem ser usados ??para armazenar qualquer coisa - as preferências do usuário, sua última pontuação elevada, ou um token de sessão. O navegador não tem idéia do que cada cookie é usado para. I deseja meus cookies para estar sempre disponível para o site que eles set, e eu quero o site para certificar-se de que leva as precauções necessárias.

Ou você está dizendo que se você procurar yahoo para "gmail" e clique no link que leva você para http: //mail.google.com , você não deve estar conectado, , mesmo que você disse gmail para manter você conectado em , porque você clicou no link de outro site?

Answer 2

Não é que um navegador está enviando o cookie para ou a partir de um domínio externo é, é o fato de que você está autenticado e o site não está validando a origem do pedido, por isso trata-o como se o pedido veio do site.

Tanto quanto se um navegador deve impedir que ... o que acontece com as muitas situações em que os pedidos de cross-site são desejáveis?

Edit:. Para ficar claro, o cookie não é enviado através de domínios

Answer 3

Eu não sei que há muito o navegador pode fazer nessa situação desde o ponto de um ataque XSRF é direcionar o navegador para outro ponto no aplicativo que iria realizar algo ruim. Infelizmente, o navegador não tem idéia se ou não o pedido está sendo direcionado para envio é malicioso ou não. Por exemplo, dado o exemplo clássico de XSRF:

<img src="http://domain.com/do_something_bad" />

não é aparente para o navegador que algo ruim está acontecendo. Afinal, como é que ele sabe a diferença entre aquele e este:

<img src="http://domain.com/show_picture_if_authenticated" />

Answer 4

Muitos dos antigos protocolos têm falhas de segurança grandes - acho que volta para o recém-descoberto vulnerabilidades DNS . Como basicamente qualquer segurança de rede, é da responsabilidade dos pontos finais; sim, é uma porcaria que temos de corrigir isso nós mesmos, mas é muito mais difícil de correção no nível do navegador. Há algumas mais óbvias ( parece muito suspeito, certo?), Mas sempre haverá casos extremos. (Talvez seja um script GD em um arquivo PHP, afinal.) E sobre consultas AJAX? E assim por diante ...

Answer 5

Os cookies para um site nunca são enviados para outro local. Na verdade, a implementação de um ataque CSRF bem sucedido, o atacante não precisa ter acesso a esses cookies.

Basicamente, um atacante engana o usuário, que já está conectado ao site de destino, a clicar em um link ou carregar uma imagem que vai fazer alguma coisa no site de destino com as credenciais do usuário.

i., O usuário está realizando a ação, eo atacante enganou o usuário a fazê-lo.

Answer 6

Algumas pessoas disseram que não acho que há muito o navegador pode fazer.

Veja este:

http: //people.mozilla. org / ~ bsterne / content-security-policy / origem-header-proposal.html

É uma visão geral de uma proposta de um novo cabeçalho HTTP para ataques CSRF ajudar a mitigar.

O nome do cabeçalho proposto é "Origem" e é basicamente o cabeçalho "Referer" menos o caminho, etc.