Differentiation of HTML-capable text blocks

I stumbled upon a potential security issue regarding allowed HTML-tags. Since we happen to need additional tags (i.e. script-tags for integrating Twitter feeds) under some circumstances not differentiating between frontend and backend text blocks creates a situation in which every user could actually use those tags. It could be a workaround to just allow scripts with relative paths but that might be even more complicated in order to avoid cross site scripting. Not allowing the src option on the other hand would allow other very annoying and potentially harmful operations.

It would be very helpful if we were able to just specify different/additional tags just for backend texts (like Journal Descriptions or similar).

Kind regards
Dennis

P.S.: the forum software might need a tweak in order to just escape the angle brackets …

Hi @dtwardy,

I’m afraid I’m not following fully – can you post a concrete example?

The forum uses Markdown formatting – see e.g. this reference for information on Markdown. If for example you’re posting code you’ll need to format it accordingly.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

When I allow the <\script>-tag in config.inc.php in order to include a live Twitter feed (for example) then the <\script>-tag will be available to everyone. That might lead to security issues (potential x-site-scripting, spoofing, phishing) concerning the user accounts and could also render the website inaccessible when misused in a harmful way.

It would be very helpful if the allowed html-tags could be defined for frontend and backend text blocks separately. Usually the texts/scripts added by the editorial staff could be seen as trustworthy whereas texts entered by visitors/readers/new users has to be handled as potentially malicious.

Best wishes from Berlin,
Dennis

P.S.: thanks, wasn’t aware of the usage of Markdown.

Hi @dtwardy,

It’s definitely risky to add the <script> element to the list of allowed HTML! However, I suspect it’s not the allowed_html configuration setting that’s preventing you from adding script contents to e.g. custom blocks – it may be that the TinyMCE editor isn’t allowing it. See e.g. this thread.

Where are you trying to add e.g. Twitter feed code?

Regards,
Alec Smecher
Public Knowledge Project Team

Oh it does work fine. I’ve tested that already. The TinyMCE is escaping the script as CDATA elements. I’m adding the Twitter feed to the #additionalHomeContent-div. But that’s just one of many possible use cases. For example when trying to deactivate the common-stylesheets that are always in use regardless of the chosen theme (in OJS 2.4.x) you have to rely on Javascript if you don’t want to or can’t modify the templates. Or when trying to move the #navbar without modifying the the templates.

I know, it would be better to actually write a dedicated theme for those cases but not everyone has the chance or resources to write one – not to mention possible issues with hosting agencies. I’m writing an advanced design guide and am trying to assess the possibilities without theming (that’s part 3).

Best wishes,
Dennis

Hi @dtwardy,

Generally I’m not fond of approaches that allow “unsafe” (e.g. Javascript-containing) HTML to be entered in web-facing forms; I’d favour small widget-supporting plugins as we’ve done for e.g. Google Analytics, Piwik, etc. These plugins are pretty small but our plugin ecosystem isn’t as strong as e.g. Wordpress, obviously, and I take your point about not wanting to write these.

Regards,
Alec Smecher
Public Knowledge Project Team

Reading through the other thread you’ve mentioned that TinyMCE might not use the same sanitising mechanisms to filter out HTML-tags that are not specifically allowed it might not even be necessary to actually allow <script>. I’ve just deleted that part and TinyMCE still processes the Javascript-code nicely. So my assumption that it was necessary to activate it in config.inc.php was wrong. That’s good new for me but maybe not so good news for OJS?

Still, I think it would be a good idea to implement a feature to specify different sets of allowed html-tags or maybe additional html-tags for backend use.

Thanks for your support!
Dennis

P.S.: It’s not so much about not wanting to write/use plugins as about some users that can’t due to institutional restrictions or standardised hosting processes. Personally I prefer writing a proper theme (which will be part 3 of the design guide).

Hi Alec,

Did something happen to the forum website? No CSS formatting in Chrome. Thanks.

Was looking for a list of current themes that have been created and are available as well as an updated list of plugins. The page for the old list seems very out of date.

Thank you!

Richard A. DeVito Jr.
Publisher
Weston Medical Publishing, LLC, 470 Boston Post Road, Suite 301, Weston, MA 02493 USA
radjr@pnpco.com - 781-899-2702 ext. 107 - 781-899-4900 fax
Join us at the 2017 International Conference on Opioids, June 11-13, 2017

Hi @radjr,

The forum is also misbehaving on some mobile devices – I’ve already asked someone to look at it over here.

Could you re-post your question as a new thread? It’s not related to this one.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks. I could not post…just reply to your email!