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.
In this document:
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 its original API.
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 or 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 takes great care 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.
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.
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 are the most prevalent:
Attack |
Prevention method |
Recommendations |
---|---|---|
Most of APS JS SDK widgets do not allow not sanitized code. |
Only a few widgets allow some unsanitized code intentionally as explained later. Follow the XSS prevention rules when using those widgets. |
|
Prevented in APS JS SDK by transparently using a user token in HTTP requests. |
Use APS JS SDK modules to input, output and process data. |
|
Prevented in APS JS SDK by using a user token in HTTP requests. |
Use APS JS SDK modules to input, output and process data. |
|
Mitigated in APS JS SDK by isolating an application JavaScript code in an IFrame. |
In the JavaScript code, do not try to go outside the current IFrame. |
|
Prevented in APS JS SDK due to thorough testing. |
When including your own or a third-party library or framework, ensure they are tested for known vulnerabilities. |
At the moment of writing, in the environment, we consider here, the most dangerous types of attacks are the cross-site scripting (XSS) attacks, in particular, the type known as stored XSS or persistent XSS.
One such attack can affect many users and the whole system by means of the following malicious actions:
Malware deployment
User data leakage
Accounts hijacking
Platform break-ins
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 the user panel is open in.
The main cause of stored XSS attack vulnerability is the output of unsanitized 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. This is the 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 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 not-escaped content:
iconName
backgroundImage
pattern
content
and innerHTML
in aps/Output
widgets
The above list can be changed in later versions of the platform.
Warning
Those exclusions make the respective widgets prone to the embedding of harmful 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 stored XSS attacks:
Do not switch off the HTML escape mechanism in the output widgets.
Do not (unless absolutely necessary) use the not-escaped properties listed above to output data.
Validate the input data wherever possible.
If you must 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 widgets or of two different ones:
An input field is used to enter a resource name. The entered data is not validated and can therefore contain JavaScript code.
One of the not escaped properties includes the entered resource name as a variable. This property will activate the inserted JavaScript code.
Some applications try to get access outside of their IFrame where they may read
some properties (including sensitive ones) of other applications. One such known way is when
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 this reason, 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.
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.