Information exposure through Link header by guessing an allocated URI

Aberta
#1,586 1 comentário 1 reação 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
javascript
Domínio
backend, security

Direção de pesquisa

Rastreie o tratamento das requisições GET e a geração do cabeçalho Link para caminhos existentes e inexistentes. Compare as requisições não autenticadas e não autorizadas para /foo/bar e /foo/baz; considera-se concluído quando o cabeçalho Link estiver consistentemente ausente nessas requisições negadas e o comportamento de divulgação pretendido estiver coberto por testes.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

security

NSS responds to unauthenticated and unauthorized GET requests to /foo/bar (that exists) by including the HTTP header:

Link: <bar.acl>; rel="acl", <bar.meta> rel="describedBy", <http://www.w3.org/ns/ldp#Resource>; rel="type"

For GET requests to non-existing resources eg. /foo/baz, the response doesn't include the HTTP Link header.

Thus, the security consideration: existence of a resource can potentially be known by guessing or anticipating an allocated URI.

There are use cases where the server may want to reveal the information in the Link header in the response. If the server doesn't make the distinction between intentionally revealing and unintentionally exposing, the server is encouraged to minimize information leaking. So, in the case here, it should be consistent by omitting the Link header for unauthenticated and unauthorized requests.

Linguagem predominante
JavaScript
Estrelas
1.8k
Forks
308
Nenhum PR com merge em 30d

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de nodeSolidServer/node-solid-server

Todas as issues de nodeSolidServer/node-solid-server

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.