Gal Goldstein

**Nome do software vulnerável e versões afetadas** Versões do Go anteriores à versão corrigida **Descrição** O problema diz respeito ao ReverseProxy no Go, que inclui parâmetros de consulta não processados da solicitação de entrada, incluindo parâmetros não analisáveis rejeitados pelo net/http, o que pode permitir o contrabando de parâmetros de consulta quando um proxy Go encaminha um parâmetro com um valor não analisável. Após a correção, o ReverseProxy sanitiza os parâmetros de consulta na consulta encaminhada quando o campo Form da solicitação de saída é definido após o retorno da função ReverseProxy Director, indicando que o proxy analisou os parâmetros de consulta. Proxies que não analisam parâmetros de consulta continuam a encaminhar os parâmetros de consulta originais inalterados. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões do Harbor anteriores à 2.5.2 **Descrição** A vulnerabilidade permite que usuários mal-intencionados visualizem, atualizem e excluam políticas de Webhook de outros usuários devido a uma falha na validação das permissões do usuário. Isso pode ser explorado por meio do endpoint da API “GET /projects/{project name or id}/webhook/policies/{webhook policy id}”, especificando diferentes IDs de políticas de Webhook. O invasor poderia modificar políticas de Webhook configuradas em outros projetos. **Recomendações** Para versões do Harbor anteriores à 2.5.2, atualize para o Harbor v2.5.2 ou posterior o mais rápido possível. Como solução alternativa temporária, considere restringir o acesso ao endpoint da API “GET /projects/{project name or id}/webhook/policies/{webhook policy id}” para minimizar o risco de exploração.

**Nome do software vulnerável e versões afetadas** Versões do Harbor anteriores à 2.5.2 **Descrição** O problema decorre da falha na validação das permissões do usuário ao atualizar uma conta de robô pertencente a um projeto ao qual o usuário autenticado não tem acesso. Ao enviar uma solicitação para atualizar uma conta de robô e especificar um ID e um nome de conta de robô que pertencem a um projeto diferente, era possível revogar as permissões da conta de robô. Isso pode ser feito por meio do endpoint da API “PUT /robots/{robot id}”, especificando o `robot id` de uma conta de robô em um projeto ao qual o usuário não tem acesso. **Recomendações** Para versões do Harbor anteriores à 2.5.2, atualize para o Harbor v2.5.2 ou posterior o mais rápido possível para corrigir o problema. Como solução alternativa temporária, considere restringir o acesso ao endpoint da API “PUT /robots/{robot id}” para impedir atualizações não autorizadas em contas de robô até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Harbor anteriores à 2.5.2 **Descrição** O problema decorre da falha do Harbor em validar as permissões do usuário ao atualizar políticas de imutabilidade de tags. Isso pode ser explorado enviando-se uma solicitação para atualizar uma política de imutabilidade de tags com um ID pertencente a um projeto ao qual o usuário atualmente autenticado não tem acesso, permitindo que o invasor modifique políticas de imutabilidade de tags configuradas em outros projetos. O endpoint da API `PUT /projects/{project name or id}/immutabletagrules/{immutable rule id}` está envolvido neste problema. **Recomendações** Para versões do Harbor anteriores à 2.5.2, atualize para o Harbor v2.5.2 ou posterior o mais rápido possível para corrigir o problema. Como solução alternativa temporária, considere restringir o acesso ao endpoint da API `PUT /projects/{project name or id}/immutabletagrules/{immutable rule id}` para minimizar o risco de exploração.

**Nome do software vulnerável e versões afetadas** Versões do Harbor anteriores à 2.5.2 **Descrição** O Harbor falha na validação das permissões do usuário ao atualizar políticas de retenção de tags. Ao enviar uma solicitação para atualizar uma política de retenção de tags com um ID pertencente a um projeto ao qual o usuário atualmente autenticado não tem acesso, o invasor poderia modificar políticas de retenção de tags configuradas em outros projetos. Isso pode ser feito enviando uma solicitação para o endpoint da API “PUT /retentions/{id}”. **Recomendações** Para versões do Harbor anteriores à 2.5.2, atualize para a versão 2.5.2 ou posterior para proteger seu sistema. Como solução temporária, considere restringir o acesso ao endpoint da API “PUT /retentions/{id}” até que um patch seja aplicado. Evite usar o parâmetro `id` no endpoint da API afetado com projetos aos quais o usuário atualmente autenticado não tem acesso, até que o problema seja resolvido.

**Nome do software vulnerável e versões afetadas** Versões do Harbor anteriores à 2.5.2 **Descrição** O problema decorre da falha do Harbor em validar as permissões do usuário ao ler e atualizar logs de execução de tarefas por meio dos logs de execução do P2P Preheat. Ao enviar uma solicitação para ler ou atualizar os logs de execução do P2P Preheat e especificar IDs de tarefa diferentes, usuários mal-intencionados autenticados poderiam ler todos os logs de tarefa armazenados no banco de dados do Harbor. Isso pode ser feito enviando uma solicitação para o endpoint da API “GET /projects/{project name}/preheat/policies/{preheat policy name}/executions/{execution id}/tasks/{task id}/logs”. **Recomendações** Para versões do Harbor anteriores à 2.5.2, atualize para o Harbor v2.5.2 ou posterior o mais rápido possível para corrigir o problema. Como solução alternativa temporária, considere restringir o acesso ao endpoint da API “GET /projects/{project name}/preheat/policies/{preheat policy name}/executions/{execution id}/tasks/{task id}/logs” para minimizar o risco de exploração.