Validate `Host` and `Origin` independently in `DnsRebindingProtectionMiddleware`
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
Direção de pesquisa
Start by locating DnsRebindingProtectionMiddleware and reading its current handling of the Host and Origin headers. The issue raises two alternative designs and does not identify files or tests; first determine the project’s existing middleware and test conventions. Done means validating Host on every request and, if present, Origin separately with its own allowlist, including scheme and port.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
The current DnsRebindingProtectionMiddleware handles Host and Origin as alternatives:
- If an
Originheader is present, only its hostname is checked. - Otherwise, the
Hostheader is checked. - Both values are checked against the same
allowedHostslist.
This causes several issues:
- An invalid
Hostheader is not rejected when an allowedOriginheader is present. HostandOriginrepresent different parties:Hostidentifies the target MCP server, whileOriginidentifies the web origin initiating the request. They commonly have different values and therefore require separate allowlists.- Origin validation is reduced to the hostname. This makes it impossible to distinguish origins by scheme or port, even though those are part of the web-origin tuple.
Would it make sense to either:
- Split this into separate Host and Origin validation middleware; or
- Extend
DnsRebindingProtectionMiddlewarewith separateallowedHostsandallowedOriginsoptions, validatingHoston every request and additionally validatingOriginwhenever it is present?
I would be happy to submit a pull request if this direction is acceptable.
- Linguagem predominante
- PHP
- Estrelas
- 1.6k
- Forks
- 173
- Merge médio
- 19h 19min
- PRs com merge (30d)
- 8
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de modelcontextprotocol/php-sdk
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
modelcontextprotocol/php-sdk#516 ·
Mantenedores costumam responder em até 1 dia
-
[Server] Handler type uses bare Closure, hard to decorate RegistryInterface under strict PHPStanAbertaServer
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100
modelcontextprotocol/php-sdk#468 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
needs confirmation needs maintainer action Server
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
modelcontextprotocol/php-sdk#398 · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
modelcontextprotocol/php-sdk#370 ·
Mantenedores costumam responder em até 1 dia
-
enhancement
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 69/100
modelcontextprotocol/php-sdk#521 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de modelcontextprotocol/php-sdk
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 2 dias
-
UX
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
ProfessionalWiki/NeoWiki#1573 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
endoflife-date/endoflife.date#11194 ·
Mantenedores costumam responder em até 1 dia