Project

Profile

Help

Issue #7462

auth token used in registry requests are not validated properly when behind an SSL proxy

Added by jsherril@redhat.com about 2 months ago. Updated about 1 month ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
High
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Platform Release:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Katello
Sprint:
Sprint 81
Quarter:

Description

When the content app is running over HTTP deployed behind a reverse proxy running on HTTPS, the content app does not properly detect the url that the request is coming in as and fails to validate the provided auth token.

As an example, my CONTENT_ORIGIN is set to "https://hostname.example.com", a fetch to the api, would generate an auth token based on this URL:

https://hostname.example.com/pulp/container/default_organization-foo-foobar/manifests/latest

however, when the request is redirected to that URL, and proxied back to the content app, the content app tries to get the URL that is coming in and gets a url that looks like:

http://hostname.example.com/pulp/container/default_organization-foo-foobar/manifests/latest?validate_token=BLAH

It seems to think that the request is coming in over 'http' since the content app is running over http. In addition, it seems to be ignoring the port #, so if CONTENT_ORIGIN was configured to a non-standard port, comparison would also fail (although this is not a concern for us at this time).

I think it makes sense to just create and validate the token based off the request path, and ignore hostname, protocol, and port

Some relevant links showing why/where this is a problem: https://docs.aiohttp.org/en/stable/web_advanced.html#deploying-behind-a-proxy https://github.com/aio-libs/aiohttp/blob/72b5344af59ccdefc1e9a9e489c222a2b2592c7d/aiohttp/web_request.py#L384-L386 https://github.com/pulp/pulp_container/blob/789979a8706c527e4c9e8d04d084b262ea78208f/pulp_container/app/models.py#L442

Associated revisions

Revision b6d54914 View on GitHub
Added by dkliban@redhat.com about 1 month ago

Use the path and query string of the URL to generate a 'validate_token'.

fixes: #7462 https://pulp.plan.io/issues/7462

Revision b6d54914 View on GitHub
Added by dkliban@redhat.com about 1 month ago

Use the path and query string of the URL to generate a 'validate_token'.

fixes: #7462 https://pulp.plan.io/issues/7462

Revision e6b9e932 View on GitHub
Added by dkliban@redhat.com about 1 month ago

Use the path and query string of the URL to generate a 'validate_token'.

fixes: #7462 https://pulp.plan.io/issues/7462

Revision e6b9e932 View on GitHub
Added by dkliban@redhat.com about 1 month ago

Use the path and query string of the URL to generate a 'validate_token'.

fixes: #7462 https://pulp.plan.io/issues/7462

History

#1 Updated by jsherril@redhat.com about 2 months ago

  • Description updated (diff)

#2 Updated by dkliban@redhat.com about 2 months ago

I was able to reproduce on my machine. I had to ensure that the 'CONTENT_ORIGIN' setting was set to https://localhost

#3 Updated by ekohl about 1 month ago

A common way with reverse proxy setups is https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto. Looks like Django has docs on this and https://docs.djangoproject.com/en/2.2/ref/settings/#secure-proxy-ssl-header suggests to use this setting:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

#4 Updated by mdellweg about 1 month ago

wrote:

[...] I think it makes sense to just create and validate the token based off the request path, and ignore hostname, protocol, and port [...]

I agree. This would be compatible with whatever strange url rewrite rules a user might apply on his reverse proxy (well almost, but we need to assume something for the hash).

#5 Updated by pulpbot about 1 month ago

  • Status changed from NEW to POST

#6 Updated by dkliban@redhat.com about 1 month ago

  • Assignee set to dkliban@redhat.com

#7 Updated by dkliban@redhat.com about 1 month ago

  • Sprint set to Sprint 81

#8 Updated by dkliban@redhat.com about 1 month ago

  • Status changed from POST to MODIFIED

#10 Updated by dkliban@redhat.com about 1 month ago

  • Sprint/Milestone set to 2.0.1

#11 Updated by pulpbot about 1 month ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF