Como os servidores da Web impõem a política de mesma origem?

Estou aprofundando o desenvolvimento de APIs RESTful e, até agora, trabalhei com algumas estruturas diferentes para conseguir isso. É claro que eu segui a política de mesma origem e agora estou me perguntando como os servidores da Web (em vez de navegadores) a impõem. Pelo que entendi, alguma aplicação parece ocorrer no final do navegador (por exemplo, honrando um cabeçalho de Controle de Acesso-Permitir-Origem recebido de um servidor). Mas e o servidor?

Por exemplo, digamos que um servidor Web esteja hospedando um aplicativo Web Javascript que acesse uma API, também hospedada nesse servidor. Presumo que o servidor imponha a política de mesma origem --- para que somente o javascript hospedado nesse servidor possa acessar a API. Isso impediria que outra pessoa escrevesse um cliente javascript para essa API e a hospedasse em outro site, certo? Então, como um servidor da web seria capaz de parar um cliente mal-intencionado que tentaria fazer solicitações AJAX para seus pontos de extremidade da API enquanto alegava estar executando o javascript originário desse mesmo servidor da web? Qual é a maneira como os servidores mais populares (Apache, nginx) protegem contra esse tipo de ataque? Ou o meu entendimento disso está de alguma forma errado?

Ou a política de origem é aplicada apenas no cliente?

A mesma política de origem é uma restrição totalmente baseada no cliente e foi projetada principalmente para proteger usuários , não serviços . Todos ou a maioria dos navegadores incluem uma opção de linha de comando ou configuração para desativá-lo. O POP é como cintos de segurança em um carro: eles protegem o motociclista no carro, mas qualquer um pode escolher livremente não usá-los. Certamente , não espere que o cinto de segurança de uma pessoa impeça que saia do carro e o ataque (ou acesse o serviço da Web).

Suponha que eu escreva um programa que acesse seu serviço da Web. É apenas um programa que envia mensagens TCP que incluem solicitações HTTP. Você está solicitando um mecanismo do lado do servidor para distinguir entre solicitações feitas por meu programa (que podem enviar qualquer coisa) e solicitações feitas por um navegador que possui uma página carregada de uma origem permitida. Simplesmente não pode ser feito; meu programa sempre pode enviar uma solicitação idêntica àquela formada por uma página da Web.

A política de mesma origem foi inventada porque impede que o código de um site acesse conteúdo restrito a credenciais em outro site. Por padrão, as solicitações do Ajax são enviadas com todos os cookies de autenticação concedidos pelo site de destino. Por exemplo, suponha que eu carregue acidentalmente http://evil.com/, o que envia uma solicitação para http://mail.google.com/. Se o POP não estivesse no lugar e eu estivesse conectado ao Gmail, o script em evil.compoderia ver minha caixa de entrada. Se o site evil.comquiser carregar mail.google.comsem meus cookies, ele pode usar apenas um servidor proxy; o conteúdo público de mail.google.comnão é um segredo (mas o conteúdo de mail.google.comquando acessado com meus cookies é um segredo).

A política de mesma origem é imposta no lado do cliente. Se o navegador suportar o CORS , o servidor poderá enviar cabeçalhos de retorno que instruem o navegador a fazer exceções à política de mesma origem. Por exemplo, enviando o cabeçalho

 Access-Control-Allow-Origin: www.example.com

diria ao navegador para permitir solicitações de várias origens em www.example.com.

 Access-Control-Allow-Origin: *

informa ao navegador para permitir todas as solicitações de origem cruzada para esse recurso.

Os servidores Web geralmente evitam ataques desse tipo, verificando a linha (com erros de ortografia incorreta) Refererno cabeçalho HTTP, para garantir que uma solicitação seja proveniente de uma página em seu próprio site. Não há uma boa maneira de se proteger contra um cliente mal-intencionado, mas não é assim que os ataques XSRF funcionam.

O cliente não é malicioso; geralmente é um usuário comum que foi enganado por terceiros maliciosos para abrir um documento que silenciosamente faz uma solicitação HTTP usando os cookies armazenados do cliente. Portanto, se o servidor puder verificar por meio de Refererque a solicitação HTTP é proveniente do gmail.com, e não do MyAwesomeWebsite.com, poderá interromper o ataque.

Como os servidores da Web impõem a política de mesma origem?

Em suma, eles não o fizerem, como apsillers e Dirk apontou.
Um motivo importante é que o cabeçalho ACAO protege os servidores contra ataques desenfreados de DDOS, - Distributed Denial of Service - .

Quem:

O ACAO como cabeçalho de resposta HTTP deve ser interpretado como cliente da Web, operando sob a suposição de que a maioria dos usuários humanos da Internet está navegando na Web através dos principais fornecedores de navegadores que aderem e implementam o rascunho recomendado pelo W3C . Afinal, eles devem se beneficiar de uma Internet rápida e acessível.

Quão:

Caso contrário, qualquer pessoa poderia copiar e colar algumas linhas de código javascript em um site mal-intencionado que executa um loop simples, o que faz uma solicitação do Ajax GET ou POST para um domínio externo. Sem interação do usuário e a capacidade de multithread.

É por isso que você precisa ativar o acesso a um site de origem cruzada, através do cabeçalho HTTP da ACAO . Você, o usuário, pode acessar o site a qualquer momento por meio de uma interação com o usuário, ou seja, um link da Internet. Assim como você pode copiar ou colar o conteúdo do usuário da ou para a área de transferência, mas de nenhuma outra maneira - deixando de lado os plug-ins.

Futuro:

Nesse ponto, observe a direção do fabricante do navegador da Web de:

• remoção de plug-in padrão , como um passo em direção a um ambiente totalmente protegido
• removendo a opção de usuário para desativar o javascript

As restrições de segurança podem ser estabelecidas decentemente usando uma combinação de TSL 2/3, IDs de sessão fortes, TANs, autenticação de dois fatores etc.

'Google' tem isso para mostrar e dizer sobre DDOS

Por fim, qualquer pessoa é livre para proxy de qualquer conteúdo da Web e adicionar um cabeçalho ACAO desejado para acessar o conteúdo entre sites em proxy. Da mesma forma, esse proxy é tão aberto a um ataque DDOS, como a configuração do ACAO permite. Na verdade, não conheço uma única oferta de serviço público gratuita. Por favor corrija-me se eu estiver errado.

Como outros disseram, cabe ao cliente. Mas o servidor pode precisar lidar com o XSS, que ignora o SOP.

Suponha que seu servidor permita que os usuários enviem conteúdo, que é exibido quando outros usuários navegam no seu site. Esta página é um bom exemplo: acabei de enviar conteúdo e ele é exibido para você.
Se meu conteúdo contiver a <script>tag e o servidor copiá-la para o HTML gerado, o script que enviei será executado.
Como o script foi encontrado em HTML no seu arquivo, ele tem todas as permissões do script do seu site. Pode, por exemplo, aprovar esta resposta. E é por isso que esta resposta tem tantos votos positivos.

Um bom servidor da Web (como, infelizmente, o que o StackExchange usa) não permitirá que isso aconteça. Ele pode remover a <script>etiqueta ou escapar dela, para que seja vista, mas não executada (aviso - esta resposta está longe de ser uma receita confiável para evitar o XSS).

Portanto, é o lado do cliente que aplica o SOP, mas em alguns casos o servidor deve trabalhar para evitar ignorá-lo.