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?
Respostas:
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:
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
fonte
É 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 .
fonte
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
fonte