Highwetneb

**Nome do software vulnerável e versões afetadas** Versões do OpenRefine anteriores à 3.8.3 **Descrição** A vulnerabilidade diz respeito ao endpoint `/extension/gdata/authorized`, que inclui o parâmetro GET `state` literalmente em uma tag `<script>` na saída, sem escapar. Isso permite que um invasor direcione ou redirecione um usuário para uma URL maliciosa contendo código JavaScript, que seria então executado no navegador da vítima como se fosse parte do OpenRefine. O parâmetro `state` é lido do arquivo controller.js e usado no arquivo authorized.vt sem nenhuma verificação de formato ou confirmação de que a página foi aberta como parte do fluxo de autorização. Isso pode levar à execução de JavaScript arbitrário no navegador do usuário, permitindo potencialmente que o código fornecido pelo invasor execute ações como excluir projetos, recuperar senhas de banco de dados ou executar expressões arbitrárias. **Recomendações** Para versões anteriores à 3.8.3, atualize para a versão 3.8.3 para corrigir o problema. Como solução temporária, considere restringir o acesso ao endpoint `/extension/gdata/authorized` até que a atualização seja aplicada.

**Nome do software vulnerável e versões afetadas** Versões do OpenRefine anteriores à 3.8.3 **Descrição** A vulnerabilidade permite que um invasor direcione um usuário para uma página maliciosa que envia um formulário POST contendo código JavaScript incorporado. Esse código seria então incluído na resposta, juntamente com um cabeçalho `Content-Type` controlado pelo invasor, e potencialmente executado no navegador da vítima como se fosse parte do OpenRefine. O código fornecido pelo invasor pode realizar ações como excluir projetos, recuperar senhas de banco de dados ou executar expressões Jython ou Closure arbitrárias, caso essas extensões também estejam presentes. O invasor deve conhecer um ID válido de um projeto que contenha pelo menos uma linha. **Recomendações** Para versões anteriores à 3.8.3, atualize para a versão 3.8.3 para corrigir o problema. Como solução temporária, considere restringir o acesso ao comando `export-rows` ou desativar o recurso até que um patch esteja disponível. Além disso, restringir a substituição do cabeçalho `Content-Type` e exigir um token CSRF pode ajudar a mitigar o problema. Também é recomendável adicionar um cabeçalho Content-Security-Policy à resposta para desativar scripts e outros conteúdos potencialmente executáveis.

Nome do software vulnerável e versões afetadas: Versões do OpenRefine anteriores à 3.8.3 Descrição: O comando `load-language` no OpenRefine espera um parâmetro `lang` para construir o caminho do arquivo de localização a ser carregado, no formato `translations-$LANG.json`. No entanto, nas versões afetadas, ele não verifica se o caminho resultante está no diretório esperado, permitindo que o comando seja explorado para ler outros arquivos JSON no sistema de arquivos. Recomendações: Para versões anteriores à 3.8.3, atualize para a versão 3.8.3 para resolver este problema. Como solução temporária, considere restringir o acesso ao comando load-language para minimizar o risco de exploração. Além disso, certifique-se de que o caminho normalizado seja verificado para estar no diretório esperado, a fim de impedir o acesso não autorizado aos arquivos.

**Nome do software vulnerável e versões afetadas** Versões do OpenRefine 3.4-beta a 3.8.2 **Descrição** O problema está relacionado à extensão `database` no OpenRefine, na qual a propriedade “enable load extension” pode ser definida para a integração com o SQLite. Isso permite que um invasor carregue e execute código arbitrário no servidor ao carregar DLLs de extensão locais ou remotas. O invasor precisa ter acesso à rede da instância do OpenRefine. A vulnerabilidade pode ser explorada para obter execução remota de código. **Recomendações** Para as versões do OpenRefine 3.4-beta a 3.8.2, atualize para a versão 3.8.3 para corrigir o problema. Como solução temporária, considere definir `enable load extension` como `false` ou restringir o acesso à extensão `database` para minimizar o risco de exploração. Além disso, considere implementar medidas de mitigação, como fazer com que os usuários enviem o arquivo de banco de dados SQLite, tornar o caminho relativo ao diretório da área de trabalho, adicionar verificações adicionais ao caminho, usar o modo de abertura READONLY e aplicar limites mais rígidos.