loio

91f3b66b6f4d1014b6dd926db0e91070
view on: demo kit nightly build | demo kit latest release

Browser Security
Browser security comprises several topics such as cross-site scripting, clickjacking, and
local storage.
A browser is, by design, an untrusted client: A server cannot rely on any information sent
from a browser, as a malicious user can use a JavaScript debugger to tamper with the client
code, or a proxy server like fiddler to modify request data. Input validation on the client is
just for convenience purposes as the server always has to validate the data again that is
received from the client.
Browsers also offer possible attack vectors, such as Cross-Site-Scripting (XSS). The
application has to take care of these.

Cross-Site Scripting
Cross-Site-Scripting has become the most prominent security issue of web applications
within the last years and also the most dangerous one, as it allows several ways of
exploitation. Once malicious code is running within your browser, it can be used to steal
your session cookies, to trigger requests within the current session, or even to exploit a
known browser vulnerability to do native code execution.
For OpenUI5 applications, XSS vulnerabilities can exist on different levels:
• Within the HTML page or custom data transports sent to the browser from the server

• Within the JavaScript code of the application, which is processing server responses

• Within the HTML renderers of OpenUI5 controls

OpenUI5 can only prevent cross-site scripting in the processing and rendering of controls.
For that purpose, input validation exists for all typed element properties and output
encoding is done in the renderer class of controls. However, there are exceptions for
controls that are especially built to include arbitrary HTML, for example,
sap.ui.core.HTML.

The application is responsible for the following tasks:

• Proper output encoding of all content embedded in the HTML page itself
• Encoding JSON or XML data sent to the client
• Secure processing of the JSON/XML data

• Security of custom controls provided by the application

For more information, see Cross-Site Scripting.

Clickjacking
Clickjacking, or UI redressing, tricks the user into triggering actions within an application
by redirecting clicks. This is done, for example, by using an invisible iFrame that is
positioned above a fake UI. When the user clicks on something on the fake UI, the content of
the invisible iFrame handles the click.
OpenUI5 provides a way to prevent clickjacking since version 1.28.0. This has to be
configured, as needed, by the application. For more information, see Frame Options.
Note: As of version 1.28.0, you no longer need to use the Business Add-In
/UI5/BADI_CONFIG_HTTP_HANDLER to configure the X-Frame-Options response header (SAP Note
2075016). The OpenUI5 framework now handles clickjacking prevention and the add-in solution won’t work on all
browsers.

For more detailed information on clickjacking, refer to the following SAP Note: 2319727

HTML5
HTML5 offers a lot of new functionality, which also brings a lot of potential new security
issues. This is just an overview of some of the new features and possible security issues
when they are used.
Local Storage
All browsers are now offering a local storage API. This API can be used to store a limited
amount of data on the browser. Access to this data is limited to JavaScript code running
from the same domain as it has been stored. OpenUI5 offers helper functions to access the
local storage on different browsers.
The local storage of browsers is not a secure storage, so while it can be used for static data,
like enumerations, applications must not store any user or application data within the local
storage.
OpenUI5 is using the local storage of the browser for the history-capability of dropdown
boxes and combo boxes.
WEBGL
While more and more browsers are supporting WEBGL by default, WEBGL allows accessing
the graphics API of the computer on a very low level, which may also lead to low level
exploits. This is the main reason why some browsers have no support for WebGL at all.
OpenUI5 is currently not using WEBGL.
WebSockets
While WebSockets offer great new possibilities for the client/server communication of web
applications, there have been many security issues rising while the first implementations
were done by the browser vendors. Standardization of WebSockets has reached a stable
state with RFC 6455 and is now implemented beginning with Chrome 16, Firefox 11 and
Internet Explorer 10. Even if the browser implementations themselves prove to be secure,
using WebSockets may require additional security measures on the client.
OpenUI5 is currently not using WebSockets.
Postmessage/Onmessage
This is another feature in the HTML5 area, which can lead to massive security issues when
not used correctly. postMessage allows inter-window-communication between windows
from different domains. This opens a hole in the same origin policy currently implemented
in the browser. As soon you subscribe to the onMessage event, you can receive messages
from any other browser window. The application is responsible to check the originating
domain and to process only messages that have been sent by trusted domains.
OpenUI5 uses postMessage for its debugging and tracing functionality.