Security and Ease-of-Use With Django Templates
This blog post is not intended to blame him for developing the package. This blog post is not intended to discourage anybody from using that package. This blog post is intended to educate about possibly risks that arise from using that package or, in general, blindly trust and run user supplied content which is something this package does to some degree.
TL;DR: We live in a dangerous world. Security is hard. Don’t trust anything.
Ok. Let’s me a bit more serious and specific. Let’s weigh the pros and cons. Let’s see what’s actually at stake.
Deploying Django applications is more complicated than your typical WordPress site. At least when you get started with Django. There are dozens of articles, conference talks, and mailing list discussions on that topic. Google it if you want specifics. In essence, deploying a Django project is not simply done by copying some files to a document root on a web server as it is common with PHP. You’ll probably use an application server like gunicorn and uwsgi. Or you figured out how to use mod_wsgi in the Apache HTTP server which then works similarly to PHP yet completely different. But when you managed to get all changes to your server, you still need to tell the application server to reload and restart your application. And this is a good thing ™. You’ll see why that is later.
When You Screw Up
Let’s assume you have this magic way to modify the HTML template files for your Django project in the browser. That’s great, as you can now make some quick fix online without the need to commit code and trigger your deployment pipeline. So it’s perfectly suitable to perform those changes from your smartphone given a responsive Django admin. Wrong!
Guess what happens when you modify your base.html file and have a syntax error in there. The potentially harmless case is a broken <a> tag, a messed up a list definition or whatnot. Or you accidentally remove the keywords from the <head> section so your SEO ranking goes downhill. None of these things actually are a real issue for the matter of this post. Your site will still be available. Users can still access your page and read its content. Modern browsers will cope with all kinds of broken HTML structures. So, all good, right? Wrong!
I think I’d prefer to completely screw up my Django template syntax. At least the issue will be brutal when the entire page won’t load. You should notice that, right? Depends! Only if you have proper monitoring or error reporting.
But that’s not all. That’s just the start. Depending on which template file you just broke, you might as as well broke your Django admin template. Congratulations, you’re now forced to figure out a way to revert that. Likely without any form of web UI. Oh, and of course, you’re on your phone in the middle of nowhere with crappy internet such that an SSH connection cracks down every 5 minutes. Sucks for you, I guess.
Something Else Is Insecure
Given the example from the introduction — a view in the Django admin that lets you modify the template files — what happens if there’s a privilege escalation in the Django admin that lets arbitrary users modify those templates. We’ll, that unfortunate! (On that note, if you encounter or think you encountered a security issue in Django, please reach out to email@example.com and do not report the issue through the issue tracker).
When To Use Such Features
Well, if you want to err on the side of caution: never.
If you do use those tools, make sure you’ve come up with a threat model and risk model. If they say the usability and user experience outweighs the risk and threat, sure, go ahead. If they say it’s too risky, well, don’t use such things.
On a higher level you can probably reduce the decision making to this: Is your site on the internet, don’t use such features. Is it company internal, e.g. behind a VPN and only a limited set of users have access to it, you’re probably fine. A company usually has bigger problems when there’s a rough admin that starts XSSing its colleagues. Is it your own tool you use for yourself only and nobody else has access to it, sure, go ahead, use such tools if they make your life easier.
In the end it comes down to the Security, Functionality and Ease-of-Use triad where you can only ever actually achieve 2 of them.
These are some thoughts I had on the initially linked tweet. I wanted to write them down to not forget about them. There’s probably a lot more to consider and at stake that I didn’t mention. I’m more than welcome to continue the discussion on this topic in said Twitter thread.