Custom Query (2297 matches)

This behavior was discovered first on 1.18.0 (Ubuntu 20.04) but can be reproduced with the latest docker container.

events {
    worker_connections  1024;
}
http {
    server {
        listen 80;
        proxy_http_version 1.1;
        proxy_ssl_server_name on;

        #doesn't work unless `proxy_hide_header` in location / is removed
        proxy_hide_header Link;

        location / {
            proxy_pass https://www.nginx.com;

            #works, but `proxy_hide_header` in `server` context stops working
            proxy_hide_header X-Pingback;
        }
    }
}

sudo docker run -p 3000:80 -it -v /home/dmitry/nginx.conf:/etc/nginx/nginx.conf:ro nginx

curl localhost:3000/ -I

You'll see that Link header is passed to curl (even though proxy_hide_header Link; is there). Try to remove proxy_hide_header X-Pingback; from location, restart nginx and curl again. Link header will be hidden as it should.

I wanted to set a few basic headers for all of my HTTP responses in nginx, however the current behaviour of add_header is that it is inherited from http only if a server block has no headers of its own.

I'd like to propose the addition of an inherited (or similar) keyword for the add_header directive that will allow it to be explicitly inherited by nested blocks in spite of its normal behaviour.

However, it is likely that this override may be useful for other directives that aren't inherited by default as well. The only one that springs to mind is try_files which I include in most location blocks except those that are to forbid access (where I put a deny instead).

In my particular use case I was hoping to add the X-Frame-Options: DENY header to all http responses, thus preventing all content on my sites from being placed in iframes by default (in supported browsers). This is a useful way to avoid legitimate pages being used for phishing/click-jacking in modern browsers (i.e- attacks where the user is interacting with the actual, full-featured site, but what they do is captured by the page it is embedded within). Unfortunately most of my server blocks have a custom header of some kind, particularly SSL server blocks (which have an HSTS header) so add_header under http has no effect.

It's fairly trivial in this case I admit, but I think that allowing users to override inheritence behaviour when they know they want to is useful.

running nginx in docker (nginx:mainline, currently 1.19.0) to serve static files, I have added the usual set of headers via add_headers like this:

server {
  listen                *:80 default_server;
  server_name           _;
  server_tokens         off;

  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;
  add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-hashes' 'unsafe-inline';";
  add_header Referrer-Policy strict-origin;
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options SAMEORIGIN;
  add_header X-XSS-Protection 1;

  location / {
      root   /usr/share/nginx/html;
      index  index.html index.htm;
  }
}

When a request is made to a path without index file, directory listing is denied (rightfully so) and a 403 status is returned. When this happens, none of the extra headers are returned. These additional headers should always be returned, it makes us fail security certifications because automated scanners find pages without the proper headers set.

While I don't have an example at hand, I could imagine that there is a scenario where being able to circumvent additional headers during a request in this way might enable or at least aid some kind of malicious action.