I recently conducted a security assessment and was able to leak the environment variables of a Django web app. This is a blog post explaining how I did it, and I hope you'll learn something new.

I will be referring the website to target.com in this post. I started the assessment with some fuzzing. I added target.com/<any_random_value> and realize DEBUG mode was enabled and the app was built with Django.

After some research, I found that by triggering a 500 Internal Server Error, I could cause it to return sensitive information. I tried sending multiple malformed requests, but there wasn't much luck as the developers had done a good job setting up the exception handling. However, during this process, I realized that the web app was running on Azure Front Door.

Azure Front Door is a CDN-based cloud service that helps you distribute traffic globally. When you set up Front Door it creates a default hostname like target-3g45k7hf.azurefd.net then the developer maps custom domain (like target.com) to this Front Door hostname. Developers often only add target.com to the ALLOWED_HOSTS list in Django's settings.py, since requests are expected to come from target.com.

So if I send a request directly to the Azure Front Door domain, it could trigger a 500 Internal Server Error, eventually leaking sensitive information. I realized this and used dig -t A target.com command to retrieve the front door domain.

I then sent a request to the Front Door domain found using the above command, and it revealed sensitive information, including environment variables, library versions, and several other details.

Using these secrets, I was able to access the web app's message broker. Always set DEBUG = False in public-facing apps and consider hardening ALLOWED_HOSTS by adding the Front Door hostname.

Thanks for reading till the end; I hope you found this useful.