Rate limit bypassable by explicitly setting the x-forwarded-for header

[jviide]

Version

nuxt-security: v0.10.0
nuxt: v2.13.0

Reproduction Link

https://github.com/jviide/nuxt-security-repro

Steps to reproduce

• Clone the repository linked above.

• In the repository directory, Install dependencies, build and start the server:

  npm i
  
  npm run build
  
  npm start

• Let's simulate a situation where Nuxt server is running behind a typical load-balancer that appends the originating request IP to the x-forwarded-for header.

  While the server is running (assuming http://localhost:3000 in this example), request the root page twice with curl. Observe the 429 response on the second request due to the rate limit:

  curl -H 'x-forwarded-for: 192.168.0.2' http://localhost:3000
  
  curl -H 'x-forwarded-for: 192.168.0.2' http://localhost:3000

• Now run the requests again, this time prefixing the x-forwarded-for header with some unique value for each request.

  This simulates the situation where the original requester sends requests where the x-forwarded-for header is manually set to unique values, and the load balancer just appends to the header. Observe how the rate limiting is not triggered:

  curl -H 'x-forwarded-for: 1.1.1.1, 192.168.0.2'  http://localhost:3000
  
  curl -H 'x-forwarded-for: 2.2.2.2, 192.168.0.2'  http://localhost:3000

What is Expected?

The rate limiter, set to 1 request per hour, could be expected to be triggered in both examples above.

What is actually happening?

In common proxy / load balancer scenarios the rate limit is not triggered if the requester manually adds unique values to the x-forwarded-for request chain.

Many load balancers and proxies just append to the x-forwarded-for headers, keeping such unique client-submitted values in the chain. This in turn can be used to trick nuxt-security's x-forwarded-for based rate limiting logic to consider each request to originate from a unique source. This could allow bypassing e.g. brute-forcing protections.

Other libraries, like Express and fastify-rate-limit, have had to deal with this problem too. For example Express exposes the "trust proxy" configuration value to define how many hops in the x-forwarded-for chain are considered valid.

[jviide]

Whoops, I had left the reproduction repository private. It's public now 👍

[Baroshem]

Thanks @jviide for this intersting issue. I will take a look at it in the next days :)

[Baroshem]

Hey @jviide

Sorry for no contact on my side. A lot of things were going on recently.

I planned to take up this issue for next major release 0.11.0.

As an issue author, maybe you would like to develop a proof of concept or a rough interface of the new functionality? That would help me a lot :)

[Baroshem]

I figured out that maybe this case is just too advanced for the built in rate limiter.

The main idea behind the default rate limiter is to protect small and simple projects. For anything more advanced, I would recommend to just use different services such as fail2ban.

I am closing the issue right now as not planned. If there will be more interest in that topic, feel free to reopen :)