Validate `Host` and `Origin` independently in `DnsRebindingProtectionMiddleware`
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- PHP
- Estrellas
- 1.6k
- Forks
- 173
- Merge medio
- 19 h 19 min
- PR fusionados (30 d)
- 8
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de modelcontextprotocol/php-sdk
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
modelcontextprotocol/php-sdk#516 ·
Los mantenedores suelen responder en 1 día
-
[Server] Handler type uses bare Closure, hard to decorate RegistryInterface under strict PHPStanAbiertoServer
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
modelcontextprotocol/php-sdk#468 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
needs confirmation needs maintainer action Server
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
modelcontextprotocol/php-sdk#398 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
modelcontextprotocol/php-sdk#370 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
modelcontextprotocol/php-sdk#524 ·
Los mantenedores suelen responder en 1 día
Todos los issues de modelcontextprotocol/php-sdk
Issues similares
-
bug No Code Attached Yet
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
joomla/joomla-cms#48556 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 3 días
-
Перевод устарел
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
-
Form
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
symfony/symfony-docs#23159 ·
Los mantenedores suelen responder en 3 días