Bypassing DRF throttling

userq3vN 0
Viewed 37

I have a Django application running on an Nginx + Gunicorn server where I use DRF throttling. Whenever I make API requests to my server and change the X-Forwarded-For header value in the client I'm then able to bypass the throttling for unauthenticated users and thereby have unlimited access to the API. This is of course not desired.

I think a way to deal with this is to have Nginx append the real IP to the end of the X-Forwarded-For request header before it reaches the server by using proxy params. It just doesn't seem to change the header when I inspect Postman / RapidApi client. I assume that's what causes the error but ultimately I don't know.

Nginx conf:

location / {
    include proxy_params;
    proxy_pass http://unix:/run/gunicorn.sock;
}

The proxy_params file from Nginx includes setting the X-Forwarded-For request header like so:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Can somebody tell me what I'm doing wrong and how to fix it so you can't make unlimited API requests? If you need more information or clarification please let me know.

nginx django-rest-framework django
1 Answers

DRF throttling is not a reliable solution to mitigate DDOS attacks. There are some known vulnerabilities to bypass DRF throttling in the wild:

  1. security vulnerability: bypass throttling
  2. Bypass Throttling based on source ip address
  3. Implementing Django-rest API Throttling and Unauthenticated bypass

It is highly recommended to use other 3rd party solutions for DDOS and brute force mitigation.

You can customize DRF throttling to patch the mentioned vulnerability. But keep in mind it is not the secure solution!

DRF throttling uses X-Forwarded-For HTTP header to generate a key to limit access. As described in the official docs, customization is implemented by inheriting throttling.BaseThrottle:

class RandomRateThrottle(throttling.BaseThrottle):
    def allow_request(self, request, view) -> bool:
        # Your custom logic here...

Request header is available in allow_request() and you can use other fields (like User-Agent)to check the uniqueness of the request originator. You can also add a little randomness.

Check here for a list of HTTP header fields.

Note: allow_request() should return a boolean.

Note: Checking other fields patches only your mentioned vulnerability, and it is just better than the defaults.

Pouya Esmaeili0
Related