Mura Basics: Cross-Site Scripting (XSS) Protection
September 10, 2015 by Michael Evangelista
Keeping Things Clean
Mura CMS provides a strong layer of cross-site scripting protection for all form elements, leveraging the tag filtering methods found in Portcullis.cfc to remove any apparent HTML or other scripted code within the values submitted in a form. Any form value deemed to contain an invalid tag such as <iframe> <script> or other potentially unwanted elements is replaced with a custom text string. By default this string is " [INVALID] ", making it very apparent to the submitter and recipient of any form data that disallowed content was attempted and removed. (Also, by replacing the contents of the form field with this marker, rather than simply formatting the contents into safe or usable HTML, the submitter is prevented from easily rebuilding the malicious string based on the stripped-down or encoded contents.)
Exceptions to the Rule
While the built-in protections are robust and smart enough to do their job unmanaged in most situations, there are times when a developer does want to allow coded form field contents to be posted or submitted as-is, especially when working in the Mura Site Manager, where CKeditor is used specifically for the purpose of creating and inserting rich text or HTML content into Mura's database.
Since the cleaning of form content applies to both back-end and front-end forms, the primary rich text editor area for any Mura content item, the Body field, is automatically excepted from this replacement of content with the [INVALID] string, allowing for the full use of restricted HTML tags in this specific admin form field. By default, all other form fields are sanitized and protected from XSS injection.
However, like most systems within Mura, there is a built-in way to customize this functionality. To extend this exception to other form fields in any Mura site, allowing for otherwise restricted tags such as an <iframe> for embedding remote content, simply look for these values in the Mura settings file, found at [site root]/config/settings.ini.cfm:
If these values to not already exist in the settings.ini.cfm file, it is safe to add them. Then, simply add the field names of any excepted fields to the exceptions list, being sure of case and omitting any extra spaces:
This will allow the matching field names to be bypassed when checking for excepted tags. As with any alteration to the settings.ini.cfm file, be sure to reload the Mura application after saving the changes.