Prevention of Cross-site Scripting (XSS) on SAPUI5

Before I'm going to explain how we can prevent this type of issue in our SCP environment, I'd like to talk to you that problem can ocurr in any time and place if you don't prevent it! Now, I want you imagining for a moment that you were writing and testing a SAPUI5 application:

You have realized you could access another informations if you had passed other information through the JS when the application have called the OData through F12 on the Browser. But this must not happening never!

What is XSS?

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user's browser.

Cross-site scripting (XSS) can be prevented by ensuring that it is not possible to inject script code into an application page that runs in a browser.

Controls must prohibit writing scripts to the page that comes from the application or from business data saved by a different user. To ensure this, the following two measures must be combined:

Validation of typed control properties

• SAPUI5 core validates the value of properties set by the application against the type of the property. This guarantees that an int is always an int, and a sap.ui.core/CSSSize is a string representing a CSS size and does not contain a script tag. This also applies to enumerations and control IDs. The control renderer can rely on this check when writing the HTML. Property values that are typed in this way can be written without escaping.

Escaping

• Control developers must ensure that string control properties and other values coming from the application and not sufficiently typed to rule out script tags being contained are escaped when written to the HTML. For this, the RenderManager and SAPUI5 core provide helper methods.

Avoiding XSS for a New Renderer

To ensure maximum security for a renderer, note the following:

• For control properties, always use the most specific type that is available. For example, use sap.ui.core/CSSSize instead of string and instead of sap.ui.core/string for control properties that refer to a CSS size.
• Use helper methods to escape the value of a string property that is written to the HTML:

1. Use writeEscaped(oControl.getSomeStringProperty()) instead of just write(...) for writing plainly to the HTML.
2. Use writeAttributeEscaped("someHtmlProperty", oControl.getSomeStringProperty()) instead of just writeAttribute(...) for writing attributes.
3. Use jQuery.sap.encodeHTML(oControl.getSomeStringProperty()) for string properties where none of the other two options is possible to escape the string and then process it further.

• Check your HTML coding whether application values can make their way into the HTML:

1. Check where the variable values come from: Can the application set a value directly or only decide which of the hardcoded values are used?
2. Escape values given in parameters in method calls of controls because they are currently not validated by SAPUI5 core.
3. Keep in mind that XSS can happen anywhere and anytime in CSS classes, or in styles.

And the backend?

We don't never forget about the backend too! Never, never, never! On the Frontend we need to worry about Screen Rules and How these informations on the screen will persist in our Model, ok?

Thats right.

Before all the information persisting in our backend, we need to prevent the Model too. Does not matter if the Frontend is working against XSS, we must prevent the backend even so and even It causes double check on the information.

Double check for what? Before all the information will have been sent through OData to the Database.

If your RFC on the backend uses, for example, PERNR as Input field, first you must test your RFC if that user login is the same user for the PERNR field too.

In this way, we prevent both the backend and the frontend! 

Let me know if you have any doubts! Please, share and comment this topic. :)

Fabiana Bacon - SAP Cloud Platform Solutions Architect