Hardening Mura

Common InfoSec issues and solutions

Presented by Eddie Ballisty

Follow along



Information security, sometimes shortened to InfoSec, is the practice of preventing unauthorized access, use, disclosure, disruption, modification, inspection, recording or destruction of information. It is a general term that can be used regardless of the form the data may take (e.g. electronic, physical).

What does that mean?

In practice this has meant a few things for our professional services projects.

Generally it's a combination of an automated scan and then a more in-depth manual scan.

First Time

Multiple issues reported.

Some issues could be fixed by server config.

Other issues had to be fixed by core Mura code.

Iteration cycle lasting two months.

The Good news

We got past the initial shock.

The end goal was to create a more secure Mura.

All code fixes would be rolled into Mura core.

Commonly Reported Issues

  • Critical - Arbitrary Code Execution
  • Critical - Weak SSL Ciphers
  • High - Arbitrary File Upload
  • High - Persistent XSS (Systemic)
  • High - Cross Site Request Forgery (CSRF)
  • High - Arbitary File Download / Read

(More) Commonly Reported Issues

  • Moderate - Excessive Network Exposure
  • Moderate - Stack Trace Enabled
  • Moderate - Lack of Click Jacking Protection
  • Moderate - Server Defaults Not Removed
  • Moderate - Improper Cookie Settings

What can be fixed with Mura?

In the next few slides, we'll go over how to solve some of the common issues that have been reported over time.

Arbitrary Code Execution

Arbitrary Code Execution

Arbitrary code execution vulnerabilities describe a collection of different vulnerabilities that ultimately result in your system executing code not expected or supplied by you.

What does that mean?

In practice this has meant that Mura was allowing any file type to be uploaded via the Admin File Manager which could then be executed in some potentially malicious way.


Mura settings.ini.cfm to the rescue.

	fmshowsitefiles=0 //site files
	fmshowapplicationroot=0 //root
	autodiscoverplugins=false //disable auto plugin

We limited the File Manager access.

White-listed the file extentions and mime types allowed.

These settings also helped address the Arbitrary File Upload issue as well.

One Stone!

Extra credit

Limit [mura] Tag

	function setDynamicContent() {
	// only allow content renderer functions
	var allowedExpressions = this;
	var allowed = false;
	trimmedExpression = left(expression, pos-1);
	for (var i in allowedExpressions) {
	  if (i == trimmedExpression || "$.#i#" == trimmedExpression) {
	    tempValue=evaluate("##" & expression & "##");
	    allowed = true;
	if (!isDefined("tempValue") || !isSimpleValue(tempValue) || !allowed) {

But Why?

One less way to cause issues

[mura] tag can still be used, but only in pre-defined functions

Extra (extra) Credit

Disable access to plugins

Disable access to modules


function onGlobalRequestStart($) {
	if (!$.getCurrentUser().isSuperUser() && listFindNoCase("cSettings.editPlugin,cSettings.deployPlugin,cSettings.updatePlugin,cSettings.updatePluginVersion", $.event('muraAction'))) {
		var s = {
			'error': 'This install does not support plugins.';
		application.userManager.getCurrentUser().setValue('errors', s);
		location('?muraAction=cSettings.list', 'false');

function onAdminHTMLHeadRender($) {
	var returnVar = '';
	if (!$.getCurrentUser().isSuperUser()) {
		returnVar = "<script>$(document).ready(function(){$('#tabModules .fieldset').html('
This install does not support configuration of modules.
')});</script>"; } return returnVar; }


Persistent XSS (Systemic)

Persistent Cross-Site Scripting (XSS) vulnerabilities happen when malicious client-side code is stored by the application and is later returned, as part of a response, to other end users. The client-side code is then executed on the victim user’s browser in the context of their current session.

What does that mean?

In practice this has meant that Mura was unintentionally allowing unsanitized html / javascript to be submitted


Again, settings.ini.cfm can help

stricthtml=true //no html unless allowed
stricthtmlexclude= //no exceptions (default)
scriptprotect=true //use Portcullis 
allowsimplehtmlforms=false //only form builder 

Mura is now configured to disallow saving html in any of its beans.

It's also configured to use the Portcullis library.

We disabled simple forms, which allows us to structure data and eliminate any free-form html / javascript.

Extra Credit

Esapi encode function

  • url
  • css
  • javascript
  • html_attr
  • html

// even if my_custom_value contains a script tag,
// esapiEncode will escape it
My Value: esapiEncode('html', $.content('my_custom_value'));


Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery, also known as a one-click attack or session riding and abbreviated as CSRF (pronounced sea-surf) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike Cross-Site Scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser.

What does that mean?

In essense, it would be possible for an attacker to load an iframe of Mura and then potentially update or delete data or account information.


Every form in Mura had to be wired to accept a one time generated CSRF token.

As you can imagine, this was one of the most invasive fixes.

Thankfully that's now said and done.

Custom Code

Mura now provides a few CSRF related functions that you can (and should) include in your custom code.


Example use within a custom form:

... $.renderCSRFTokens(format='form'); ...

Results in:

... ...

Validate token:

if( $.validateCSRFTokens() ) {
	// passed the test

Stack Trace Enabled

Stack Trace Enabled

Having stack traces enabled provides attackers with additional information about the system.

What does that mean?

In practice this has meant we need to disable any debugging or error output.




In ACF or Lucee admin, set the error template to the same file.

Lack of Click Jacking Protection

Click Jacking

Attackers can trick victims into unknowingly clicking and invoking unwanted requests / transactions. This can result in a broad variety of possible exploits.

What does that mean?

This issue is related to the CSRF issue in the sense that attackers are trying to load a page and have the end user unknowingly interact with a site.


We set the X-Frame-Options header

  • DENY
  • ALLOW-FROM uri:

In other words, if you specify DENY, Mura cannot be loaded via an iframe.

If you specify SAMEORIGIN, you can still use the page in a frame as long as the site including it in a frame it is the same as the one serving the page.

ALLOW-FROM uri: lets a specified uri load Mura in an iframe.

Place the following in /config/cfapplication.cfm

cfheader(name="X-Frame-Options", value="SAMEORIGIN");

Improper Cookie Settings

Improper Cookie Settings

Cookies that may contain sensitive information, such as session identifiers, should be set with appropriate cookie flags; Specifically, the Secure and HTTPOnly flags.

What does that mean?

To prevent cookies from being read over non SSL connections, we should specify the Secure flag in our cookies.

The HTTPOnly flag instructs the browser to not allow JavaScript to read the cookie value, adding one more layer of protection.

There is one last layer of protection we need to address which includes rotating the session identifier cookie after login.


Here we have another baked in Mura settings.ini.cfm solution.


We also need to instruct ACF or Lucee to not set client cookies.

// add the following in /config/cfapplication.cfm
this.setClientCookies = false;

In order for secure cookies to function, we the site has to run over SSL.

Enter https://LetsEncrypt.org

What have we covered?

Common InfoSec reported issues.

Mura settings to help remediate issues.

Don't fear the scan

A good InfoSec team will continutally scan, and that means new findings.

In the long run, it's all for the greater good.

Hopefully a new found resepect for information security.