Security risks and mitigation when using builtin templates "|safe" properly

Using Django Getting Started
1

In another forum thread, Ken made a side note:

This is curious and I have some questions but since it is kind of a unique issue, I decided to start a new thread. So here it is.

For slightly additional context, here is the template I am currently working with:

{% extends 'base.html' %}
{% block content %}
   {% if contents %}
      {{ contents.body|safe }}
   {% endif %}
{% endblock %}

But the specific line in question Ken already identified which is the one that reads: {{ contents.body|safe }}

The Django docs explain built-in filters available for writing templates. Here is the marker for the safe filter in the docs. It’s used to enable website users to add body text content with HTML markup.

In the use case for my CMS website, the only users with the permission to add content to that body attribute (TextField) are about 6 hand-picked people I know and see in real life on a regular basis who I will personally authorize. I will be the only staff admin and will grant them selective group permissions to post body hypertext with the aid of a WYSIWYG editor. So not only do I “trust” them (not random visitors creating accounts) and can verify their identity in real life, they are additionally non-technical. By “non-technical”, I mean they would be incapable of performing an SQL injection or exploiting any similar attack vector by inserting malicious code.

So as far as I am concerned (and I could be wrong - - I would be happy to have someone correct me) with the specs outlined above, the so-called aircraft carrier threat isn’t an issue.

I can see and understand how and why using Django to write a message board web app (for the sake of comparison) which enables any public web visitor to create an account and begin posting content - - in this context, using the |safe filter would be extremely foolish because it would enable all kinds of potential drastic malicious activity. That’s a fair assessment, agreed?

But that scenario / configuration isn’t present with my site because my users who have write permission for posting content - - not only do I trust the small number of them - - they also aren’t sophisticated enough to exploit any such security vulnerability.

So far I have addressed the security aspect and I welcome any feedback if someone wants to jump in to correct me.

The other good point Ken made was that mismatched HTML tags could disrupt the intended appearance when Django serves a template in a web browser. I can see that happening. What is the best way to mitigate this issue while still allowing authorized content writers to style their text using a WYSIWYG tool like CKEditor?

2

Note, this:

is a security issue. (The formal definition of “informations security” goes beyond the common usage of referring to “security” in terms of preventing the leak of information. The confidentiality and privacy of data is only one aspect of security.)

When I refer to something being a security issue, I’m also addressing the need to protect the availability and integrity of a resource.

I also contend that this:

may reduce the chance of malicious activity, but does not prevent it. Nor does it prevent problems being created by one of those “non-technical” users who have copy/pasted some text or examples from another site - or something given to them from someone else.

It also doesn’t prevent a third-party who manages to acquire those credentials from accessing the site and causing problems due to a credentials leak.

(It’s generally accepted that at least half of all “attacks” involve internal personnel either directly or indirectly.)

Now, whether your site ends up being an attractive target is an entirely different issue. I’ve got a site that I run that has a couple of similar issues - but I acknowledge and accept those risks.

Notice there’s a difference of perspective here. I’m not denying that the problems exist - I freely acknowledge that someone getting staff credentials to that site can easily destroy it. But I can also recover that site in less than a day and the 8 - 10 people using it wouldn’t care. And since this site doesn’t have a profile high enough where people not knowing it exists would come looking for it, a few simple steps keep it secure enough for me.

“Best” is relative - everything’s a trade off. You could try to implement some type of html filtering, where only certain tags are permitted and the html is structurally validated before being accepted. But I know in general those types of mechanisms usually have flaws.

If I had a site where this were an issue to concern me, I’d be looking to implement something like a Markdown editor. Look at this forum as an example. I’m editing in a panel on the left and seeing the to-be-displayed version on the right.

The bottom line here is that “security” is not a binary evaluation. Something isn’t “secure” or “not secure”. One option may be more- or less- secure than a different option, but both those options might be “secure enough” for your needs. (Or neither may be “secure enough”.)

In any case, these types of decisions should be made in the context of how much risk are you willing to accept. You want to look at the worst-case scenario, and what the effect on you is going to be if it happens. (Financially and otherwise) You then want to evaluate the likelihood of that happening.

If you decide the risk is acceptable, that’s fine. That’s a valid decision to make. But you want to make those types of decisions from a position of knowledge, not from the lack thereof.

1 Like