Safe mode *must* disallow attributes like "onload", "onclick" #82

fletom opened this Issue Mar 5, 2012 · 2 comments


None yet

2 participants

fletom commented Mar 5, 2012

Possibly by disabling attributes altogether (like enable_attributes=False), or by applying a filter. There is a fairly comprehensive list at

This is the mode that people are expected to use when rendering user input. This has to be the default, especially since most people don't know about or use this attribute syntax in the first place. The output must be actually guaranteed safe, not just partly safe. This vulnerability is just as dangerous as javascript: links.

{@onclick=alert('hi')}some paragraph

In fact, all Django sites that user markdown current have this vulnerability, because the markdown template filter does not pass enable_attributes=False when called with 'safe'.

waylan commented Mar 5, 2012

As we have documented:

Note that "safe_mode" does not alter the enable_attributes option, which
could allow someone to inject javascript (i.e., {@onclick=alert(1)}). You
may also want to set enable_attributes=False when using "safe_mode".

Unfortunately, this is an issue of poor naming. Perhaps it should have been called "raw_html" rather than "safe_mode". However, we have left it for historical (backward compatible) reasons. Too many other libraries and projects expect the current name so we leave it.

The fact is, with our extension API, we have no way of ensuring that any third party extensions are "safe" either. If you really want something that is "safe", then I suggestion a third party post-processor which completely sanitizes markdown's output. Perhaps something like bleach.

I should also note that this request is for a blacklist that blocks "attributes like 'onload', onclick'." Whereas solutions like bleach implement a whitelist. Whitelists block everything that is not known to be safe, which is a much safer approach. If markdown was to continue on this blacklist approach, we would constantly be chasing new "unsafe" input. For that reason, we will not be implementing the suggested solution. As existing solutions already exist, I'm closing this wontfix.

@waylan waylan closed this Mar 5, 2012
fletom commented Mar 5, 2012

You are right that a blacklist is never the right answer. I meant a filter of non-whitelisted attributes, and only providedthe blacklist for reference.

It's not an issue of poor naming. The "safe" mode does more than just not interpret "raw_html", like filtering javascript: links. It should do as it says and make the output safe.

I understand that backwards compatibility is an issue, but security is even more important. Security should always be the default, not an extra option like enable_attributes. I suspect that many, many sites using markdown have this vulnerability. Not fixing it would be simply irresponsible.

@waylan waylan reopened this Mar 26, 2012
@waylan waylan added a commit that closed this issue May 3, 2012
@waylan Fixed #82. 'enable_attributes' honors 'safe_mode'.
Note that you can still explicitly set 'enable_attributes' and that
value will be honored regardless of 'safe_mode'. However if 'safe_mode'
is on and 'enable_attributes' is not explicitly set, then
'enable_attributes' defaults to False.
@waylan waylan closed this in c64c196 May 3, 2012
@waylan waylan added a commit that referenced this issue May 3, 2012
@waylan Updated docs to reflect fix in #82. 6cf7e40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment