Security Vulnerabilities and Content Modeling

Introduction

Part of LogicNets' security architecture is implemented at the modeling level and impacts how  you can build content safely.  This topic discusses security steps, but you can reach out to your Account Manager for more information about the security architecture in place for the LogicNets platform.

UI Security

LogicNets set the security level to ‘safe’ as part of security improvements implemented to guard against cross-site scripting (XSS). This means that the system performs HTML escaping for all interpolated text--text that is rendered from $(..) in the output of all UI parts.

LogicNets implemented this safeguard to help content modelers build safer applications and to create awareness that $(..) can potentially allow malicious user inputs that contain XSS vulnerabilities, such as script statements. For example, a data object containing 

<b>My Caption</b>

 will be printed as <b>My Caption</b> on screen, instead of My Caption.

The above example is quite harmless. However, if you had a scenario where your application displayed the user name on screen as ‘Hello $(user_name)’, bad actors would be able to enter as their user name scripts that could allow for XSS:

<script>alert(“Hey I can run malicious code from this site”)</script>

HTML escaping prevents this from happening, as the system renders the caption as text only.

For additional information about  and examples of XSS, go to https://owasp.org/www-community/attacks/xss/.

HTML-Escaped Parts

Below is the list of LogicNets form parts that are more secure because of HTML escaping:

• Text Input
• DbGrid
• Text Area
• Check Box
• RadioList
• DropDown
• CheckList
• Numeric Input
• Date Input
• Title
• Warning
• Error
• Button
• DbGrid
• Upload
• Download
• HTML

There may still be times when you want to use the $(..) construction for dynamic resolution of formatted labels or captions, for example. If you are confident your content will be safe during your application's runtime, you can use the html(..) function inside the $(..) to prevent escaping the content.

For example, you have a data object called user_message and it contains the following:

<b class="error">An error has occurred</b>

use $(html(user_message)) to ensure that the HTML is not escaped in the comment node.

Set Data Object

In addition to the above form parts, the set data object process part has an option to set the value as html, marking the content as a safe HTML string.

Non-HTML-Escaped Parts

There are some LogicNets parts that are used to render static content and safe HTML, and these are not HTML escaped. These parts are:

• Title
• Warning
• Error
• HTML parts/nodes that include the text HTML, comment, and format-variable parts

LogicNets has added a part parameter called Escape $(…) text to these parts to enable automatic escaping of the $(..) text in the captions, if desired and determined to be safe. This parameter is enabled by default for newly added nodes.

Locating Security Weaknesses in Existing Modeled Content

To facilitate the migration of applications to the new security standard you can run the validation tool on each of your projects. This allows the system to provide you an overview of those parts with $(..) in the output that are affected by this change.  The system displays a warning in the node and part editors and in the project-validation tool when text, comment, and format-variable parts are used with $(…) in captions and the “escape-$()-text” flag is not set.

Resolving Security Weaknesses

You can resolve warnings by enabling the escape-$(..) text flag.

When you use $(html(safe_text)) to explicitly indicate that content is safely formatted HTML, the system does not show a warning message.

The validation tool also offers the option to automatically resolve the vulnerabilities. If you choose this, the validation tool will do the following:

• Enable the escape-$()-text flag in the comment and format-variable part declarations in the models.
• Convert the text HTML part to a comment part.

Security Vulnerabilities of Client-Script Part

With the client-script part (write_script) there are similar security vulnerabilities that could allow a bad actor to execute JavaScript in the browser modeled in a logicnet. Consequently, you should use this part with care. We strongly recommend the following when using this part:

• Properly encode all data inserted into the script using $(..).
• Call the JavaScript encode method for strings:
  myfunction("$(encode_js(…))").
• Do not JavaScript-encode a JSON encoded string when using it directly in a data object:

  var json=$(json_str)

•  If you use JSON.parse you must JavaScript-encode your data:

  JSON.parse("$(encode_js(json_str))")