O que impede o código malicioso de falsificar o cabeçalho "Origem" para explorar o CORS?

Pelo que entendi, se um script do lado do cliente em execução em uma página do foo.com deseja solicitar dados do bar.com, na solicitação deve especificar o cabeçalho Origin: http://foo.come a barra deve responder Access-Control-Allow-Origin: http://foo.com.

O que existe para impedir que códigos maliciosos do site roh.com simplesmente falsifiquem o cabeçalho Origin: http://foo.compara solicitar páginas da barra?

Os navegadores controlam a configuração do Origincabeçalho e os usuários não podem substituir esse valor. Portanto, você não verá o Origincabeçalho falsificado em um navegador. Um usuário mal-intencionado pode criar uma solicitação de ondulação que defina manualmente o Origincabeçalho, mas essa solicitação viria de fora de um navegador e pode não ter informações específicas do navegador (como cookies).

Lembre-se: o CORS não é segurança. Não confie no CORS para proteger seu site. Se você estiver exibindo dados protegidos, use cookies ou tokens OAuth ou algo diferente do Origincabeçalho para proteger esses dados. O Access-Control-Allow-Origincabeçalho no CORS apenas determina quais origens devem ser permitidas para fazer solicitações de origem cruzada. Não confie nele para mais nada.

TLDR: Não há nada que impeça o código malicioso de falsificar a origem. Quando isso acontece, seu servidor nunca saberá sobre isso e agirá de acordo com as solicitações. Às vezes, esses pedidos são caros. Portanto, não use o CORS no lugar de qualquer tipo de segurança.

Venho brincando com o CORS recentemente e me fiz a mesma pergunta. O que descobri é que o navegador pode ser inteligente o suficiente para conhecer uma solicitação CORS falsificada quando vê uma, mas o servidor não é tão inteligente.

A primeira coisa que descobri foi que o Origincabeçalho é um nome de cabeçalho proibido por HTTP que não pode ser modificado programaticamente. O que significa que você pode modificá-lo em cerca de 8 segundos usando Modify Headers for Google Chrome .

Para testar isso, configurei dois domínios de cliente e um de servidor. Eu incluí uma lista de permissões do CORS no servidor, que permitia solicitações do CORS do cliente 1, mas não do cliente 2. Testei os dois clientes e, de fato, as solicitações do CORS do cliente 1 foram bem-sucedidas enquanto as do cliente 2 falharam.

Então eu falsifiquei o Origincabeçalho do Cliente 2 para corresponder ao Cliente 1. O servidor recebeu o Origincabeçalho falsificado e passou com êxito na verificação da lista de permissões (ou falhou se você é do tipo meio vazio de vidro). Depois disso, o servidor teve um bom desempenho consumindo todos os recursos que foi projetado para consumir (chamadas ao banco de dados, enviando e-mails caros, enviando mensagens sms ainda mais caras, etc.). Quando isso foi feito, o servidor enviou o Access-Control-Allow-Origincabeçalho falsificado de volta para o navegador.

A documentação que li afirma que o Access-Control-Allow-Originvalor recebido deve corresponder Originexatamente ao valor enviado na solicitação. Eles combinaram, então fiquei surpreso ao ver a seguinte mensagem no Chrome:

XMLHttpRequest não pode carregar http://server.dev/test. O cabeçalho 'Access-Control-Allow-Origin' tem um valor http://client1.dev que não é igual à origem fornecida. http://client2.dev Portanto, a origem não é permitida.

A documentação que li não parece ser precisa. A guia de rede do Chrome mostra claramente os cabeçalhos de solicitação e resposta como http://client1.dev, mas você pode ver no erro que o Chrome sabe de alguma forma a origem real http://client2.deve rejeita a resposta corretamente. O que não importa neste momento, porque o servidor já aceitou a solicitação falsificada e gastou meu dinheiro.

Apenas um resumo humilde:

P: A mesma política de origem (SOP) é ​​aplicada apenas pelos navegadores?
A: sim Para todas as chamadas feitas dentro de um navegador, o SOP é definitivamente aplicado pelo navegador. O servidor pode ou não verificar a origem da solicitação.

P: Se uma solicitação não estiver em conformidade com o SOP, o navegador a bloqueia?
R: Não, está além da autoridade dos navegadores. Os navegadores apenas enviam solicitações de origem cruzada e aguardam a resposta para ver se a chamada é sinalizada como legítima pelo servidor através de Access-Control- * cabeçalhos. Se o servidor não enviar de volta o Access-Control-Allow-Origincabeçalho, não repetir a origem do chamador ou não enviar de volta *no cabeçalho, tudo o que o navegador fará será abster-se de fornecer a resposta ao chamador.

P: Isso significa que não posso falsificar Origin?
R: No navegador e usando scripts, você não pode substituir Origin, pois está no controle do navegador. No entanto, se você quiser se hackear, poderá violar as chamadas que saem do SEU navegador usando extensões do navegador ou outras ferramentas instaladas em sua máquina. Você também pode emitir HTTPchamadas usando curl, Python, C#, etc e alterar o Origincabeçalho para servidores truque.

P: Então, se eu posso enganar o servidor alterando Origin, isso significa que CORSnão é seguro?
R: CORS por si só é silencioso sobre segurança - isto é, autenticação e autorização de solicitações. Cabe aos servidores inspecionar solicitações e autenticar / autorizá-las por qualquer mecanismo com que trabalhem, como cookies e cabeçalhos. Dito isto, pode nos proteger um pouco mais em caso de ataques como o XSS:

Exemplo: digamos que você fez login no seu site e um script malicioso tenta enviar uma solicitação ao site do seu banco para obter informações sobre seu saldo: um ataque XSS refletido . O site do seu banco confia nas credenciais provenientes (aqui em nome do) do site, para que a solicitação seja autenticada e HTTPseja emitida uma resposta visando o código malicioso. Se o site do seu banco não se importar em compartilhar seus pontos de extremidade com outras origens, ele não incluiAccess-Control-Allow-Origincabeçalho na resposta. Agora, após a chegada da solicitação, o navegador percebe que a solicitação era entre origens, mas a resposta não mostra que o servidor estava feliz em compartilhar o recurso (aqui o ponto de extremidade da consulta de saldo) com seu site. Portanto, ele interrompe o fluxo, portanto, o resultado retornado nunca alcançará o código malicioso.