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 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 which are especially built to include arbitrary HTML, for example, sap.ui.core.HTML.
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, 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 which 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 detailed information on clickjacking, refer to the following SAP Note: 2319727
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 Internet Explorer has no support for WebGL at all, Microsoft recently stated, that they are not going to support WebGL as they think it can not be implemented in a secure way.
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 great 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. So basically this opens a hole in the same origin policy currently implemented in the browser. As soon you are subscribing to the onMessage event, you can receive messages from any other browser window, the application is responsible to check the originating domain and only to process messages which have been sent by trusted domains.
OpenUI5 is utilizing postMessage for its debugging and tracing functionality.