bunkerity / bunkerweb

🛡️ Open-source and next-generation Web Application Firewall (WAF)
https://www.bunkerweb.io
GNU Affero General Public License v3.0
6.26k stars 350 forks source link

[BUG] Using variable in proxy_pass directive has side effects #218

Open quentinfougereau opened 2 years ago

quentinfougereau commented 2 years ago

Description I have an application behind bunkerized-nginx as a reverse-proxy. When I made requests to the reverse-proxy, the requests sent to the proxied server are always the same.

Expected behavior The request GET /foo/dir/ on the reverse-proxy should result in the following request on the proxied server : GET /bar/dir

Current bug But the request GET /foo/dir/ on the reverse-proxy become GET /bar on the proxied server

The bug is present since version 1.3.0 with the use of $backend variable in the proxy_pass directive.

On the nginx website, it says :

In some cases, the part of a request URI to be replaced cannot be determined:

In this case, if URI is specified in the directive, it is passed to the server as is, replacing the original request URI.

How to reproduce I used the following docker-compose file :

version: '3'

services:
  app:
    image: nginx:latest

  bunkerized-nginx:
    image: bunkerity/bunkerized-nginx:1.3.0
    ports:
      - 80:8080
      - 443:8443
    environment:
      - USE_REVERSE_PROXY=yes
      - REVERSE_PROXY_URL=/foo
      - REVERSE_PROXY_HOST=http://app/bar
      - SERVE_FILES=no
      - USE_BAD_BEHAVIOR=no
    depends_on:
      - app

Then I requested the following URL http://localhost/foo/dir/.

Logs docker-compose logs

bunkerized-nginx_1  | localhost 172.25.0.1 - - [17/Dec/2021:09:07:31 +0000] "GET /foo/dir/ HTTP/1.1" 404 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"

app_1               | 172.25.0.3 - - [17/Dec/2021:09:07:31 +0000] "GET /bar HTTP/1.0" 404 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0" "172.25.0.1"
fl0ppy-d1sk commented 2 years ago

Hello @quentinfougereau,

I don't know which way is the best for fixing this :

  1. We automatically append $request_uri if we detect a sub path in the REVERSE_PROXY_HOST
  2. We add a setting to control it e.g. AUTO_APPEND_REQUEST_URI
  3. We document that behavior and ask users to add $request_uri to their REVERSE_PROXY_HOST
quentinfougereau commented 2 years ago

Hello,

I see that the problem is still present in the latest (1.4.2) version.

To be honest, I don't know neither what is the best way, I think that the first solution is the more convenient for the users.

quentinfougereau commented 1 year ago

Hello @fl0ppy-d1sk ,

Do you have any news regarding this issue ?

Actually, we need custom conf if we want to proxy something like /back-office to http://back-office/. It could useful to configure reverse-proxy without using custom configuration.

Thanks !