How to limit access by target domain and file type? about cors-anywhere HOT 11 OPEN

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

from cors-anywhere.

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.

from cors-anywhere.

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?

from cors-anywhere.

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?

from cors-anywhere.

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.

from cors-anywhere.

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!

from cors-anywhere.

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?

from cors-anywhere.

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).

from cors-anywhere.

@FreedomFighterSparrow How we're you able to place Varnish in front of CORS anywhere? All I need is some simple steps.

from cors-anywhere.

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.

from cors-anywhere.

from cors-anywhere.