Frontend Specifics

The platform frontend allows customers and their service users to get access to the services provided by the integrated applications. The provider, resellers, and customers also use it to manage the platform and its services.

User Interfaces

Application consumers will use two types of user interfaces (UI):

• Customer staff members and end-users interact through the REST interface with the APS controller, normally via the custom UI integrated with the platform control panel. This connection is needed to deploy, provision, and manage application resources.
• End-users, when they need to consume application services, interact with the application through the application original API.

Custom UI

The APS SDK documentation concerns only the first of the above UI. When designing and developing custom UI, the APS integrators use the underlying APS JavaScript framework(APS JS SDK) to build custom UI trees with views from the predefined modules and widgets. They can also plug some views into wizards of other applications and create their own wizards to plug the views from various applications.

JavaScript is very often used by attackers to insert their code into a system. That is why the APS team pays much attention to protect the APS JS framework from possible attacks. The documentation also contains some notes and warnings to help you make a flawless custom code.

Interaction with APS Controller

UI interacts with the APS controller through the high level APS store module or the aps/xhr method based on XMLHttpRequest. In either case, the APS JS framework sends the request over the secure HTTPS channel to the APS controller. The latter identifies the actor of the request, verifies the actor’s credentials and processes the request accordingly.

Probable Threats

You can find a lot of books and online Internet resources concerning the application UI security. Among the top 10 most critical risks facing organizations, in the HTML/Javascript environment the following risks look as the most important:

Attack	Prevention	Recommendations
XSS stored	Most of APS JS SDK widgets do not allow not sanitized code.	Only a few widgets allow some of not sanitized code intentionally as explained later. Follow the XSS prevention rules when using those widgets.
XSS reflected DOM based	Prevented in APS JS SDK by using transparently a user token in HTTP requests.	Use APS JS SDK modules to input, output and process data.
CSRF	Prevented in APS JS SDK by using a user token in HTTP requests.	Use APS JS SDK modules to input, output and process data.
Sensitive Data Exposure	Mitigated in APS JS SDK by isolating an application JavaScript code in an IFrame. The 14.5.2. HTTP Requests to External Services section of the certification process prevents certification of an APS application if its code contains an attempt to get access to other IFrames.	In the JavaScript code, do not try to go outside the current IFrame.
Using Components with Known Vulnerabilities	Prevented in APS JS SDK due to thorough testing.	When including your own or a third-party library or framework, ensure they are tested against known vulnerabilities.

At the moment of this writing, in the environment, we consider here, the most dangerous are the cross-site scripting (XSS) attacks, especially one of its types, known as stored XSS or persistent XSS.

One attack of such a type can affect many users and the whole system by means of the following malicious actions:

• Deploy malware
• Leak user data
• Hijack accounts
• Break into the platform

An attacker can be a user or a malicious code from another application. The latter can run in another window or tab of the same browser that keeps open the control panel.

The main cause of a vulnerability to a stored XSS attack is the output of not sanitized data into the browser. That data may include an active code, typically JavaScript, to perform malicious actions. That code can be added by means of snippets similar to the following:

<script>Direct JavaScript code</script>
<script src="JavaScript code from a remote source"></script>
<div onload="code" onclick="JavaScript handler" onerror="Another JavaScript handler">

In most widgets provided by APS JS SDK, the described weakness is prevented by using the escape the HTML code method. It means replacement of the typical HTML markup and other special symbols with the proper numeric character references as follows:

< -> <

> -> >

& -> &

" -> 

' -> 

` -> <

Due to HTML escape, the HTML code is printed out as a plain text with all its markup characters.

However, in some cases, application developers want to display colorful text with some images. For this reason, the APS JS SDK contains a few properties in a limited number of widgets that allow a not escaped content:

• iconName
• backgroundImage
• pattern
• content and innerHTML in aps/Output widgets

The above list can be changed in the later versions of the platform.

Warning

Those exclusions make the respective widgets prone to the embedding of a harmful code.

Mitigation

Mitigate XSS in Custom Code

The main idea is to break a chain of the two steps that an attacker uses to enter a harmful code in an input widget and then an output widget sends the code to the browser for rendering.

The following rules allow you to prevent the stored XSS attacks:

• Do not switch off the HTML escape mechanism in the output widgets.
• Do not use, without strong necessity, the not-escaped properties listed above to output data.
• Validate the input data wherever possible.
• If you have to use a not-escaped property, ensure its content does not include not validated data coming from an input widget.

For example, a flaw can appear due to the following two properties of the same or of two different widgets:

• An input widget is used to enter a resource name. The entered data is not validated and thus can contain a JavaScript code.
• One of the not escaped properties includes the entered resource name as a variable. This property will activate the inserted JavaScript code.

Mitigate Access to DOM Nodes of Other Applications

Some applications can intentionally or occasionally try to get access outside of their IFrame where they can potentially read some properties, including sensitive properties, of other applications. It was noticed that some applications want to open a screen from a cloud system in the parent DOM node by transferring to the window.top or window.parent IFrames.

For the above reason, Technical Review of the application certification process contains the 14.5.2. HTTP Requests to External Services section that does not allow certification of an application if the latter contains insecure attempts to go outside its IFrame. Also, such attempts will be rejected by the APS JS framework in the control panels of the platform.

To get access to external applications, the APS JS SDK provides the secure externalHttpRequest method.

Mitigate Vulnerabilities from other Sources

There are automated tools that identify and exploit well-known libraries included into many products. It is possible to find the full range of known weaknesses in a code based on those frameworks. This makes it hard to prevent all of the caused flaws.

The typical prevention rules are published by OWASP.

← Backend Specifics

Personal Data →