Openrefine: Adicionar proteção CSRF a todos os endpoints POST
Devemos adicionar proteção Cross Site Request Forgery a todos os nossos endpoints POST, para proteger as instâncias de serem alteradas por outros sites (o que pode ser a primeira etapa em um exploit XSS).
- [x] adicionar método GET para gerar tokens CSRF
- [x] requer e valida tokens CSRF em todos os terminais POST. Provavelmente, queremos fazer isso de uma forma genérica na classe
Command. - [x] atualizar o front-end para solicitar esses tokens antes do POST
wetneb
Todos 3 comentários
@wetneb Eu me deparei com isso enquanto olhava para o código AJAX atual e me pergunto quanta proteção ele oferece. Um ataque típico, pelo que entendi, consistiria em usar a autenticação de sessão baseada em cookies do usuário para fazer uma alteração não autorizada, mas os usuários do OpenRefine não são autenticados em primeiro lugar. Além disso, como o token CSRF é buscado separadamente da página da web gerada a partir do ponto de extremidade não autenticado, um invasor pode apenas solicitar um token e usá-lo em sua solicitação forjada.
Provavelmente há algo que estou perdendo aqui, então resolvi perguntar.
tfmorris
em 20 mai. 2020
O exploit típico é o seguinte:
Suponha que alguém esteja executando o OpenRefine em http://localhost:3333/ em sua máquina.
Simultaneamente, eles vão para http://maliciouswebsite.com/ . Esse site inclui um script que submete um formulário a um endpoint POST em OpenRefine, digamos http://localhost:3333/command/core/set-preference . Esta solicitação POST pode ser acionada sem qualquer interação do usuário (basta criar um elemento <form> oculto e enviá-lo em javascript). O envio de formulários em diferentes domínios é permitido, portanto, a solicitação não será bloqueada pela política do navegador. Isso permitirá que o invasor modifique qualquer preferência do OpenRefine silenciosamente, para este comando (e é claro que você pode criar cenários mais assustadores com outros comandos).
Agora, com uma proteção CSRF, o invasor primeiro precisa obter um token do OpenRefine. Para fazer isso, eles precisam executar uma solicitação GET entre domínios para nosso back-end e ver o resultado dessa solicitação para ler o token. Isso não é permitido pela política de origem cruzada.
wetneb
em 20 mai. 2020
Entendi. Obrigado! Era a peça CORS que eu estava perdendo.
tfmorris
em 20 mai. 2020
Questões relacionadas
thadguidry
·
3Comentários
katrinleinweber
·
3Comentários
dantexier
·
4Comentários
anchardo
·
3Comentários
lapoisse
·
3Comentários
Comentários muito úteis
O exploit típico é o seguinte:
Suponha que alguém esteja executando o OpenRefine em
http://localhost:3333/em sua máquina.Simultaneamente, eles vão para
http://maliciouswebsite.com/. Esse site inclui um script que submete um formulário a um endpoint POST em OpenRefine, digamoshttp://localhost:3333/command/core/set-preference. Esta solicitação POST pode ser acionada sem qualquer interação do usuário (basta criar um elemento<form>oculto e enviá-lo em javascript). O envio de formulários em diferentes domínios é permitido, portanto, a solicitação não será bloqueada pela política do navegador. Isso permitirá que o invasor modifique qualquer preferência do OpenRefine silenciosamente, para este comando (e é claro que você pode criar cenários mais assustadores com outros comandos).Agora, com uma proteção CSRF, o invasor primeiro precisa obter um token do OpenRefine. Para fazer isso, eles precisam executar uma solicitação GET entre domínios para nosso back-end e ver o resultado dessa solicitação para ler o token. Isso não é permitido pela política de origem cruzada.