To develop a utility using the Django framework, I need to be able use the HTTP/2 protocol’s multiplexing functionality.
My first question is, is this possible in Django, and if so, how? If not, how to implement this possibility?
Thank you in advance.
Hey there, this not seems something that is going to be handled by Django (at the application level), but by your webserver.
Nginx has a http2 module that you can configure, i haven’t tried it, but it’s a good starting point.
Cool! Thanks for the tip. I’m going to have to try that to see how well it works in front of uwsgi.
I also know that Daphne handles http/2 (How to server HTTP/2 protocol with Django - #2 by KenWhitesell), but I didn’t go so far as to check out the multiplexing facilities.
after reading The single-packet attack , which motivated me to investigate ways to defend against this type of attack. As a first step, I tried to develop a vulnerable application that could bypass rate limiting by sending multiplexed requests such as Bypassing rate limits via race conditions challenge . However, I failed to do so using Django as my web framework and Daphne as the HTTP/2-compatible server.
I implemented rate limiting on an endpoint using django-ratelimit, but was unable to successfully exploit it.
This led me to the following question:
Does Using an Asynchronous Server Have an Effect on the Availability of Race Conditions?
Any insights you can provide would be greatly appreciated. Thank you in advance for your time and consideration.
Disclaimer: I am not a web security expert. The opinions I’m expressing here should therefore be considered suspect.
I definitely found the resources referenced here very educational.
Having said that, there are a lot of factors involved in vulnerabilities like this.
It could. If you’re “fully async”, then all requests being handled by a single process are being processed in a single thread. It’s possible to create a process flow that doesn’t allow for other tasks to execute while the current process flow is running.
However, what I think is more important is the fundamental architecture of your system. Everything I’m reading on that site leads me to believe that all these vulnerabilities exist as a result of two concurrent threads using non-thread-safe data structures. So the best defense in those circumstances is to ensure thread safety (either by using thread-safe data structures, or by using a “worker” model such that each request is handled by a different process), properly using database locks and transactions, or both.
For example, the login rate limit exploit could be prevented if the code that performs password validation locks the User record - preventing other reads from occurring on that row until the password test is resolved.
I think some of the examples provided, or at least some of the principles behind them, may be a side-effect of a micro-services architecture. I can see where separating a work-flow process into multiple, smaller steps can lead to the creation of the “sub-states” described.