Template Stripping Tags

I’m in fact obeying wordpress tag stripping (didn’t do that in the past). You can however configure EME to leave certain tags alone, see the setting “Extra html tags” in the EME settings, section “Other”.

Hi Franky, thanks for such a quick reply. That explains it.

Is there a wildcard option for the Extra tags? Either per-tag or overall please?

I’ve just been trying to compare what is being stripped and I’m up to 8 tags and many of them have several attributes. Whilst I can probably work this out for this specific template (because I have a before and after to compare), I’m concerned this could happen again in another part of the config and I might not know until someone reports a problem with the site. It could be as subtle as a single attribute on a tag.

I understand the rationale for sanitising user input, but for my particular use-case having div, style and center tags being stripped from admin input is more of a hinderance than an asset. Especially when I’m building HTML templates. If there’s a way to whitelist all tags (effectively turn the sanitisation off) that would be really useful. Alternatively do you know if there’s a list of sanitised tags and attributes available somewhere that I can copy/paste into the ‘Extra html tags’ box please?

Thanks again for your help and for all the time you devote to this awesome plugin.

Sorry, in fact the same sanitizing happens as for wordpress posts. So there I need to refer you to the somewhat limited wp doc on sanitizing (wp_kses function).

Thanks Franky. Looks like a decent amount of Google hits for that, I will see what I can find.

Is this something you might consider making configurable in the future please?

One of the StackExchange hits I just read on this confirms my own thoughts that: “You shouldn’t need to run wp_kses() on your own markup though, you should know it’s safe. wp_kses() is generally just for handling untrusted input from users.”

While indeed you can trust own input, if an account gets hacked or an admin gets tricked into adding extra info, this might become a problem. WP people pointed that out to me, so I decided to be more strict for this. Also, even for posts done in the admin interface the wp_kses function is used, so it is a bit logical I do this too.

There’s always a lot of opinions get banded around when it comes to Infosec, I’m a full-time Infosec bod and retired Developer, so I totally get what others have told you and I really can’t disagree with the worst case scenario’s you have highlighted to you.

Infosec done well is a balancing act though – otherwise you risk jeopardising the very outcomes that you are trying to protect.

Just some counter-points that you may or may not want to consider;

True CSRF and XSS are an existential risk, although if an Admin gets hacked or tricked into carrying out tasks there’s a myriad of ways it becomes bad news. Sanitising some of the admin input fields in EME would (IMHO) do nothing to save the day. They could inject rogue code into the HTML fields in the EME database bypassing sanitisation, they could inject through one of the fields that doesn’t have sanitisation, they could add their own javascript to one of the theme files, they could download the database, they could hook into the RSVP feature with a PHP hook, the list goes on.

Initially when I read your comment about the sanitisation for admin posts I was quite surprised, I don’t use posts so I wasn’t familiar with that. Thinking about it a bit more though, posts are short excerpts of (mostly) readonly repeating text blocks that go inside an established page/UI/theme. Because of that, limiting the use of tags to ensure the integrity of the theme/UI makes a lot of sense – you wouldn’t want a single post refining the CSS for every post on the page. On the other hand, the custom templates feature in EME is there (as I understand it) to build a full page/UI (or HTML email), in which case a richer set of tags and controls could reasonably be required.

I just thought it might be useful to put the alternative viewpoint forward, security is rarely black-and-white, context and informed risk judgement are everything. It’s your plugin and I’m certainly not going to push the issue, you will never please everyone! You build this for the good of the community and I (as well as a lot of others) are eternally grateful.

I understand your reasoning and I will take it back into consideration … maybe I’ll just strip out javascript …