POST de formulário entre domínios

145

Eu já vi artigos e postagens por todo o lado (incluindo SO) sobre esse tópico, e o comentário predominante é que a política de mesma origem impede um formulário POST entre domínios. O único lugar em que vi alguém sugerir que a política de mesma origem não se aplica a postagens de formulário é aqui .

Eu gostaria de receber uma resposta de uma fonte mais "oficial" ou formal. Por exemplo, alguém conhece o RFC que aborda como a mesma origem afeta ou não um formulário POST?

esclarecimento : Não estou perguntando se um GET ou POST pode ser construído e enviado para qualquer domínio. Estou perguntando:

se o Chrome, IE ou Firefox permitirem que o conteúdo do domínio 'Y' envie um POST para o domínio 'X'
se o servidor que recebe o POST realmente visualizar algum valor de formulário. Digo isso porque a maioria das discussões online registra os testadores dizendo que o servidor recebeu a postagem, mas os valores do formulário estavam todos vazios / removidos.
O documento oficial (ou seja, RFC) explica qual é o comportamento esperado (independentemente do que os navegadores implementaram atualmente).

Aliás, se a mesma origem não afeta os POSTs de formulário - torna um pouco mais óbvio o motivo pelo qual os tokens antifalsificação são necessários. Digo "um pouco" porque parece muito fácil acreditar que um invasor pode simplesmente emitir um HTTP GET para recuperar um formulário que contém o token anti-falsificação e, em seguida, criar um POST ilícito que contém o mesmo token. Comentários?

— Brent Arias
fonte

Sim, um invasor pode fazer isso ... com um navegador comum.

— Michael Hampton

Talvez não haja RFCs pela mesma razão pela qual não existem RFCs que digam: "não poste sua senha no seu site". Os padrões da Web são necessários apenas quando várias partes precisam trabalhar juntas para obter algo: a mesma política de origem é mais um conjunto complexo de "práticas recomendadas de segurança" que impedem que os usuários sejam invadidos.

— Ciro Santilli escreveu

@Ciro Por favor, diga explicitamente. As regras para postagem cruzada em outros sites não afetam várias partes. Não há necessidade da linguagem nebulosa.

— Little Alien

Respostas:

175

A mesma política de origem é aplicável apenas a linguagens de programação do lado do navegador. Portanto, se você tentar postar em um servidor diferente do servidor de origem usando JavaScript, a mesma política de origem entrará em jogo, mas se você postar diretamente do formulário, ou seja, a ação apontará para um servidor diferente, como:

<form action="http://someotherserver.com">

e não há javascript envolvido na postagem do formulário, a mesma política de origem não é aplicável.

Consulte a Wikipedia para mais informações

— Suresh Kumar
fonte

Desculpe arrastar uma pergunta antiga, o que aconteceria se a ação fosse alterada usando JS, mas o formulário fosse postado usando um botão? Isso permitiria uma publicação bem-sucedida entre domínios?

— 22413 Chris

AFAIK não deve ser um problema, mas eu mesmo não tentei. Seria interessante descobrir.

— precisa

Eu sou do mesmo pensamento. Na verdade, eu tinha preocupações com a segurança, algum JS / vírus de terceiros alterando a ação para postar o formulário em algum lugar malicioso, mas percebi que isso poderia ser feito em qualquer formulário de recebimento de pagamento entre domínios ou não, e o resultado seria o mesmo. Lição aqui realmente: verificar quaisquer arquivos JS terceiros;)

— Chris

Em resumo: SIM, é permitido o POST entre domínios.

— Christian Davén

-1 para: A mesma política de origem não tem nada a ver com o envio de solicitação para outro URL (protocolo, domínio ou porta diferente), trata-se de restringir o acesso a dados de resposta (de leitura) de outro URL (e, assim, impedir que o javascript atualize o documento com formulários com tokens de segurança de outros URLs).

— Mohsenme

É possível criar uma solicitação GET ou POST arbitrária e enviá-la para qualquer servidor acessível a um navegador de vítimas. Isso inclui dispositivos na sua rede local, como impressoras e roteadores.

Existem muitas maneiras de criar uma exploração CSRF. Um simples ataque CSRF baseado em POST pode ser enviado usando o .submit()método Ataques mais complexos, como ataques CSRF de upload de arquivos entre sites , exploram o uso do CORS do comportamento xhr.withCredentals .

O CSRF não viola a política de mesma origem para JavaScrip t porque o SOP está preocupado com o JavaScript que lê a resposta do servidor a uma solicitação de clientes. Os ataques de CSRF não se importam com a resposta, se preocupam com um efeito colateral ou alteração de estado produzida pela solicitação, como adicionar um usuário administrativo ou executar código arbitrário no servidor.

Verifique se suas solicitações estão protegidas usando um dos métodos descritos na Folha de dicas de prevenção do OWASP CSRF . Para obter mais informações sobre o CSRF, consulte a página OWASP no CSRF .

— Mikey
fonte

Atualizei minha pergunta para esclarecer. Além disso, o link do WordPress que você forneceu envolve explorações iniciadas no X de mesma origem, em vez de iniciadas no domínio cruzado Y ... portanto, não é o cenário certo pelo que vejo.

— Brent Arias

@Brent Arias sim, o que você está descrevendo em 1 e 2 é exatamente igual ao que um ataque de CSRF executa; talvez você deva tentar executar uma das explorações de CSRF fornecidas e detectar o tráfego. Atualizei meu post. Você deve ler todos os links fornecidos, pois ele responderá a essas perguntas com precisão. O ponto de um ataque de "falsificação de solicitação entre sites" (CSRF) é que a solicitação se origina de outro domínio, todas as explorações fornecidas atendem totalmente a esse requisito fundamental.

— Mikey

A mesma política de origem não tem nada a ver com o envio de solicitação para outro URL (protocolo, domínio ou porta diferente).

Trata-se de restringir o acesso aos dados de resposta (de leitura) de outro URL. Portanto, o código JavaScript em uma página pode ser postado em um domínio arbitrário ou enviar formulários nessa página para qualquer lugar (a menos que o formulário esteja em um iframe com URL diferente).

Mas o que torna essas solicitações POST ineficientes é que essas solicitações não possuem tokens antiforgery, por isso são ignoradas pelo outro URL. Além disso, se o JavaScript tentar obter esses tokens de segurança, enviando uma solicitação AJAX para o URL da vítima, será impedido de acessar esses dados pela mesma política de origem.

Um bom exemplo: aqui

E uma boa documentação da Mozilla: aqui

— Mohsenme
fonte