Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow proxying to metadata by default #268

Open
wafisher opened this issue Aug 19, 2020 · 3 comments
Open

Disallow proxying to metadata by default #268

wafisher opened this issue Aug 19, 2020 · 3 comments

Comments

@wafisher
Copy link

We've been running CORS Anywhere in a Docker container on an EC2 instance for about a year. After going through the flaws.cloud challenges, I realized that we used to be vulnerable to this attack by not specifying a whitelist. At some point we started specifying a whitelist, but only because it seemed to be a good idea, not because I was aware of this attach.

By the same token, anybody setting this up with the default parameters (none at all) is vulnerable to this attack. Unless I'm missing something, the defaults should prohibit user requests to proxy to 169.254.169.254, no?

The documentation implies (to me)that the worst that can happen if you don't whitelist is you run an open proxy and perhaps run up your bandwidth bill:

If you expect lots of traffic, please host your own instance of CORS Anywhere, and make sure that the CORS Anywhere server only whitelists your site to prevent others from using your instance of CORS Anywhere as an open proxy.

@Rob--W
Copy link
Owner

Rob--W commented Aug 19, 2020

For more notes on security, see https://github.com/Rob--W/cors-anywhere/issues/152.

In particular, what you're describing is covered by this comment:

The proxy server must not be placed in a network where sensitive resources are accessible via an intranet, or even localhost. Otherwise these resources can be leaked via proxy requests. I once planned to address this in #78, but haven't changed the logic yet.

CORS Anywhere doesn't support blocking by IP yet (or even blocking based on destination. By design it's an open proxy). Merely blocking the destination IP in the URL is not sufficient, because that can be circumvented by DNS (i.e. creating an A DNS record pointing to 169.254.169.254).

@wafisher
Copy link
Author

This is helpful. I think you should highlight this on main README. I would definitely have closed this loophole sooner had I known.

@wafisher
Copy link
Author

We actually don't run this proxy at all anymore but to clarify for others reading this, the whitelist does not solve this since it's the origin (not destination) whitelist. It would prevent an attack from a browser but an adversary would obviously not run the query from a browser. They would merely set the origin host to an accepted one and still hit the internal IP as the destination.

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

No branches or pull requests

2 participants