Potential Security Issue

[LeaveerWang]

Hi,

We have identified a potential security issue in this project, but the details have not yet been publicly disclosed.

We would like to collaborate with you on responsible disclosure. Could you please provide a preferred contact method for security reports? You may also reach us directly at hwang335@jh.edu.

Thank you.

[mikeckennedy]

Hi @LeaveerWang What's the problem? I'm happy to fix it if you let me know. It is NOT in production so secrecy is not needed.

[LeaveerWang]

Dear Michael,

We found Host header poisoning in the PyPI.org-style application: the sitemap viewmodel builds the site base URL from flask.request.scheme and flask.request.host. This base is passed to the sitemap XML template and used as the origin for every URL in the sitemap (homepage, login, register, and all package project URLs). In Flask, request.scheme and request.host are derived from the request (and, when using Werkzeug’s ProxyFix or equivalent, from X-Forwarded-Proto and X-Forwarded-Host). There is no validation or allowlist. If an attacker can influence the Host or X-Forwarded-* headers that reach the application, the generated sitemap.xml contains URLs pointing to an attacker-controlled host. Search engines and users that consume the sitemap may then index or follow those URLs, enabling SEO poisoning, phishing via search results, or cache poisoning in search engine results.

Tested target

• Repo: https://github.com/talkpython/data-driven-web-apps-with-flask
• Commit: 6ce1ec6

1. Sitemap base URL built from request.scheme and request.host

Where it happens
The same pattern appears in multiple chapter variants of the app (e.g. ch14_testing/final, ch15_deploy/starter, ch15_deploy/final, ch16_mongodb/starter, ch16_mongodb/final). Representative path: app/ch16_mongodb/final/pypi_org/viewmodels/seo/sitemap_viewmodel.py (line 12):

class SiteMapViewModel(ViewModelBase):
def init(self, limit: int):
super().init()
self.packages = package_service.all_packages(limit)
self.last_updated_text = '2019-07-15'
self.site = '{}://{}'.format(flask.request.scheme, flask.request.host)

The view app/ch16_mongodb/final/pypi_org/views/seo_view.py exposes GET /sitemap.xml and builds the response from this viewmodel:

@blueprint.route('/sitemap.xml')
@response(mimetype='application/xml', template_file='seo/sitemap.html')
def sitemap():
vm = SiteMapViewModel(1000)
return vm.to_dict()

The template seo/sitemap.html uses {{ site }} for every in the XML, e.g. {{ site }}, {{ site }}/account/login, {{ site }}/project/{{ p.id }}. So the entire sitemap’s URL set is rooted at request.scheme + request.host. There is no validation of the host.

Why this is vulnerable

• In Flask, request.scheme and request.host reflect the request’s scheme and host (from the Host header and, when using ProxyFix, from X-Forwarded-Proto and X-Forwarded-Host). There is no validation or allowlist. Any client or proxy that can set Host or X-Forwarded-Host can cause the sitemap to advertise URLs on an attacker-controlled host.

Impact

• The sitemap is served at /sitemap.xml and consumed by search engines and other crawlers. If the sitemap is generated with a poisoned base URL, every points to the attacker’s host. Search engines may index those URLs, leading to SEO poisoning (attacker’s site ranked for the victim’s content), phishing (users clicking “legitimate” search results that go to the attacker), or cache poisoning in search results. Users or tools that follow the sitemap will be directed to the attacker’s server.

Root cause

The sitemap viewmodel sets the site base URL from request.scheme and request.host without validating the host. No configured canonical base URL or host allowlist is used. The same pattern exists in multiple app variants (ch14–ch16 starter/final). The request’s scheme and host are trusted as-is when building the sitemap.

PoC (minimal)

We verified the vulnerable behavior by replicating the relevant logic.

1. With the app running (any chapter variant that includes the sitemap route), send GET /sitemap.xml with Host: evil.example.com (or, if the server uses proxy headers, X-Forwarded-Host: evil.example.com and X-Forwarded-Proto: https).
   Observed: The response is XML with values such as https://evil.example.com, https://evil.example.com/account/login, https://evil.example.com/project/<id>, etc. (or http if no TLS). Crawlers or users using the sitemap would then resolve URLs to evil.example.com.

This confirms that the Host header (and, when proxy headers are trusted, X-Forwarded-* headers) control the scheme and host of every URL in the sitemap when no validation is applied.

Suggested remediation

1. Use a configured canonical base URL (e.g. an env such as SITE_URL / CANONICAL_URL / APP_URL) for building the sitemap base, instead of request.scheme and request.host. Set self.site from that config in SiteMapViewModel.

2. If the request must be used when no config is set, validate request.host against a strict allowlist of known application hostnames before building any URL; reject or use a safe default for unknown hosts.

3. Only trust X-Forwarded-* when the request is from a trusted proxy (e.g. configure ProxyFix with trusted hosts). Do not allow arbitrary clients to influence the effective host.

4. Optionally enforce host and X-Forwarded-* validation at the reverse proxy (overwrite or drop these from untrusted clients and set them only from the proxy for the known hostname).

If you'd like, we can make a PR and help verify a patch.