cors-anywhere
cors-anywhere copied to clipboard
Rob--W
How to limit access by target domain and file type?
To limit the attack vector of my (local) cors-anywhere proxy, I want to limit the domains it will ferry requests to, as well as the filetypes. In my specific use case, I want to limit it only to domains under '.gov.il'. How can I go about doing so?
Thanks!
You can do "*.gov.il", the wildcard icon is any name in front of gov.il. Add that to your server.js file and save. Then run these commands in your command line
- git add . -git commit -m "some name"
- git push heroku master
Sorry, that was unclear to me - add the wildcard where? There's an "origin" blacklist/whitelist, but nothing in regards to target, as far as I can see.
This is not part of the current functionality, but I can add it.
Restricting to "file types" is pointless, because it can easily be bypassed. For example, if you want to only allow PDF files, you would think that requiring the URL to end with ".pdf" would help. This is not the case, since one can easily append "?.pdf" or "&.pdf" to the URL to bypass the check.
The only meaningful restriction has to be based on the host name. What syntax do you prefer?
Hi Rob, thanks for your response! I thought I might be missing something. I bypassed the issue by putting a Varnish Cache service in front of the proxy, but I think it will be better to do this in the proxy itself, and I guess the same whitelist/blacklist format of the Origin will work here as well.
Regarding the PDF, I can't agree with you there - after all, anything you add to the URL will be in the query string and not the path (urlObject.pathname), which is what we need to check.
However, the file type check seems to me like an uncommon use case - so how adding a callback to createServer() instead, so we can do our own filtering? Or is there one already?
Regarding the PDF, I can't agree with you there - after all, anything you add to the URL will be in the query string and not the path (
urlObject.pathname), which is what we need to check.
In theory, you're right. In practice, this heuristic doesn't cut it. On the one hand, there are sites with paths ending in .pdf that are no PDF files, e.g. https://example.com/not/a.pdf, on the other hand there are sites that serve PDF files while the path does not end with .pdf
However, the file type check seems to me like an uncommon use case - so how adding a callback to createServer() instead, so we can do our own filtering? Or is there one already?
I'm considering to add such a callback function, with a default implementation that takes the origin/domain list from the environment variables. The exact syntax is TBD.
I see. Since this is just to limit the attack surface, I'm OK with the possible omissions - but as I said, I'm doing most of that using Varnish now (which also serves my need for actual caching).
Would you like me to close this issue and open a new enhancement request for a callback function? or just close this issue? Thanks!
I'd keep this issue open. For the public demo, I am currently applying a patch on top of the default source that hard-codes checks to enforce blacklists for the few targets where I seen abuse.
By "using Varnish", do you mean that you've replaced CORS Anywhere with Varnish, or something else?
by "using Varnish" I mean that I have varnish in front of CORS Anywhere, so any requests go through it first. This allows me to add some rules easily, have some caching (which I needed anyway), but still keep all of the logic of CORS Anywhere (which I wouldn't want to duplicate in Varnish's VCL).
@FreedomFighterSparrow How we're you able to place Varnish in front of CORS anywhere? All I need is some simple steps.
I was able to figure it out by following this tutorial: https://www.digitalocean.com/community/tutorials/how-to-configure-varnish-cache-4-0-with-ssl-termination-on-ubuntu-14-04
Basically I had to decode all https traffic with Nginx, then pass it onto varnish, which would then load from the cache or pass the request onto cors anywhere.
Pretty much what I'm doing - except I'm using Hitch to terminate SSL, as that is the official Varnish recommendation (Hitch is maintained by the same people).
On Tue, 24 Mar 2020 at 17:50, Robert Stojanovski [email protected] wrote:
I was able to figure it out by following this tutorial: https://www.digitalocean.com/community/tutorials/how-to-configure-varnish-cache-4-0-with-ssl-termination-on-ubuntu-14-04
Basically I had to decode all https traffic with Nginx, then pass it onto varnish, which would then load from the cache or pass the request onto cors anywhere.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Rob--W/cors-anywhere/issues/67#issuecomment-603321379, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2CAKYBVW33B4K2E5CYJSTRJDJCTANCNFSM4DDAHQFA .