Skip to content

Add option to disable following redirects#237

Merged
willnorris merged 5 commits into
willnorris:mainfrom
basecamp:follow-redirects
Sep 10, 2020
Merged

Add option to disable following redirects#237
willnorris merged 5 commits into
willnorris:mainfrom
basecamp:follow-redirects

Conversation

@blakestoddard
Copy link
Copy Markdown
Contributor

Adds a new FollowRedirects flag that defaults to true. If the user sets it to false, imageproxy will not follow redirects and instead will use the content of the redirect (likely text/html which will result in a 403 due to the default allowed content-types list).

If you are electing to follow redirects, ensure that the host being redirected to is allowed per AllowHosts and DenyHosts. Without this, you can use a redirect to get around the allowed() logic.

@blakestoddard
Copy link
Copy Markdown
Contributor Author

blakestoddard commented Jun 20, 2020

Messed up the branch and ended up with the two commits that got squashed in master, will fix.

Fixed.

@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 20, 2020

Codecov Report

Merging #237 into main will decrease coverage by 1.38%.
The diff coverage is 15.38%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #237      +/-   ##
==========================================
- Coverage   89.28%   87.89%   -1.39%     
==========================================
  Files           6        6              
  Lines         681      694      +13     
==========================================
+ Hits          608      610       +2     
- Misses         50       59       +9     
- Partials       23       25       +2     
Impacted Files Coverage Δ
imageproxy.go 81.72% <15.38%> (-3.12%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0da684b...d79103e. Read the comment docs.

@willnorris
Copy link
Copy Markdown
Owner

Can you say a little more about the use case here? If you trust the source host enough to put them in the allowHosts list, why are you concerned about them redirecting to a disallowed host? If not all URLs on the source host are trusted, should you instead be using signatures?

@blakestoddard
Copy link
Copy Markdown
Contributor Author

Sure! We use imageproxy to proxy images in customer emails for HEY. We don’t have an allow list since we don’t want to purposefully block any customer content, but we do have a deny list with all of the IETF reserved ranges just for kicks (even if we run imageproxy in a secure environment). But even with a deny list, you can get around it by telling imageproxy to proxy a URL that 301 redirects back to one of the blocked hosts — the host in the redirect isn’t rechecked through the allow/deny lists, but imageproxy will proxy that content anyway (even if it wouldn’t of been allowed because of the initial lists).

(We do use signatures.)

@willnorris willnorris changed the base branch from master to main June 22, 2020 17:00
Copy link
Copy Markdown
Owner

@willnorris willnorris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's really cool! Happy to hear that imageproxy is useful for HEY, and congrats on working out the App Store approval stuff :)

Comment thread imageproxy.go Outdated
@blakestoddard blakestoddard requested a review from willnorris June 24, 2020 14:23
Comment thread imageproxy.go

msgNotAllowed = "requested URL is not allowed"
msgNotAllowed = "requested URL is not allowed"
msgNotAllowedInRedirect = "requested URL in redirect is not allowed"
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm kind of meh on the wording here, happy to change it to something else.

@willnorris willnorris changed the title Make redirects optional, ensure that they are still allowed per AllowHosts/DenyHosts Add option to disable following redirects Sep 10, 2020
@willnorris willnorris merged commit 52f4360 into willnorris:main Sep 10, 2020
willnorris added a commit that referenced this pull request May 12, 2023
When following redirects, ensure that the final URL is not in the
configured DenyHosts list, but do not further enforce presence in the
AllowHosts list.

This was initially added in #237, and the original use case was about
protecting against redirects being used to bypass denied hosts. They
were using URL signatures and deny lists (for localhost, etc), but not
allow lists. So really, checking against the deny list is all that was
needed in that case.

This came up recently for me as I was trying to proxy images on a remote
host that redirects to Amazon S3. Even though the original URL was
signed, the redirect was being denied because s3-us-west-2.amazonaws.com
isn't on of my allowed host. But I don't want to allow all of S3, just
the signed URLs.
vetler pushed a commit to vetler/imageproxy that referenced this pull request Apr 11, 2025
When redirects are followed, ensure that they are still allowed per AllowHosts/DenyHosts
vetler pushed a commit to vetler/imageproxy that referenced this pull request Apr 11, 2025
When following redirects, ensure that the final URL is not in the
configured DenyHosts list, but do not further enforce presence in the
AllowHosts list.

This was initially added in willnorris#237, and the original use case was about
protecting against redirects being used to bypass denied hosts. They
were using URL signatures and deny lists (for localhost, etc), but not
allow lists. So really, checking against the deny list is all that was
needed in that case.

This came up recently for me as I was trying to proxy images on a remote
host that redirects to Amazon S3. Even though the original URL was
signed, the redirect was being denied because s3-us-west-2.amazonaws.com
isn't on of my allowed host. But I don't want to allow all of S3, just
the signed URLs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants