This document provides a summary of a security review conducted on the OntoBrowser web application.
The OntoBrowser application has been built using Google’s Web Tookit (GWT). The GWT documentation includes a security chapter detailing the major classes of exploits that web applications are vulnerable to and provides guidelines on how to develop secure GWT applications.
Based on the GWT security documentation an internal security review of the OntoBrowser web application was conducted. The security review consisted of two processes:
- Code review – inspecting the code to verify that all necessary precautions have been taken to prevent known classes of exploits
- User Input tests – ensuring the application correctly escapes malicious user input to prevent Cross-Site Scripting (XSS)
A summary of the security review is provided in the sections below.
As documented in the GWT security document, there are three major classes of attacks:
- Cross-Site Scripting (XSS)
- Cross-Site Request Forging (XSRF or CSRF)
- JSON and JSONP vulnerabilities
The OntoBrowser source code was inspected to ensure the application is not vulnerable to XSS and XSRF exploits.
Note: The OntoBrowser application does not utilise JSON (or JSONP) therefore the application is not vulnerable to this class of attack. Hence the security review did not include JSON (or JSONP) exploits.
Cross-Site Scripting (XSS)
By design there are only a limited number of method calls within the GWT API that enables content to be directly evaluated by the browser. The OntoBrowser source code was searched for all such GWT methods and reviewed.
The OntoBrowser application generates SVG (and VML) on the server for visualization of ontology graphs. The markup from the server is rendered directly by the browser (intentionally bypassing GWT’s default escaping mechanism). Therefore it is imperative that the dynamic content within the SVG (and VML) markup is escaped on the server i.e. before being sent to the browser for rendering.
The SVG is generated by the third-party software library Graphviz. After careful inspection of the Graphviz code (and a series of tests) it was confirmed that the dynamic content within the SVG markup is correctly escaped.
Note: only a relatively few pre-registered and approved ontology curators are able to create dynamic content using the OntoBrowser application. Therefore the risk of malicious markup or script being created by a user is low.
Cross-Site Request Forging (XSRF)
The OntoBrowser application has been designed to operate within different environments e.g. The Internet, corporate intranets etc… User authentication (and authorization) is outside the scope of the application as it is dependent on the installation/environment.
For example, users logging into the OntoBrowser application hosted on the Novartis corporate intranet are authentication/authorised by Novartis’ internal single-sign on (SSO) system. In contrast, users of the eTOX OntoBrowser installation (accessible on the Internet) are authenticated/authorised using HTTPS Basic Authentication (provided by the user’s browser and an Apache web server).
OntoBrowser’s server-side Remote Procedure Call (RPC) service is completely stateless i.e. it does not rely on session cookies for verifying user requests. It is the responsibility of the authentication/authorisation mechanism to authentication/authorisation each request (potentially independently). As stated above the authentication/authorisation mechanism is dependent on the installation/environment and hence outside the scope of the OntoBrowser application.
Although session cookies are not used for verifying OntoBrowser RPC requests, depending on the authentication/authorisation mechanism the application is still potentially vulnerable to Cross-Site Request Forging (XSRF). For example, when using Basic Authentication the browser sends the Authorization header with each HTTP request. Therefore the risk of XSRF using Basic Authentication is greater than using session cookies (because session cookies can be configured to expire).
Note: the default method provided by GWT to eliminate XSRF attacks has been implemented for session cookies. An alternative solution (based on the default GWT implementation) would need to be developed to protect against XSRF attacks using HTTP Basic Authentication.
The following RPC write requests are currently exposed to XSRF attack when using HTTP Basic Authentication:
A successful XSRF attack calling the changePassword RPC method could potentially change a curator’s password. Although the changePassword RPC method is only relevant for some authentication/authorisation mechanisms it is still a potential security risk.
Note: Immediately following the review the changePassword RPC method was changed such that the existing password is required as a method argument and is validated before updating the user’s password. Therefore eliminating the security risk identified above.
User Input tests
There is only a limited set of user input fields exposed on the OntoBrowser application GUI. Therefore a secondary security review was conduced to test for Cross-Site Scripting (XSS) vulnerabilities resulting from malicious input via user input fields.
Note: Immediately following the review additional URL validation has been added to both client side and server side code to ensure that only valid http and https URLs are permitted therefore eliminating the security risk identified above. Furthermore a review of the database fields containing URLs confirmed that only valid http URLs have previously been entered.
Curator Password Protection ( installation)
As previously stated the OntoBrowser installation uses HTTPS Basic Authentication. Using HTTPS (rather than HTTP) means that passwords are never transmitted in plain text (as the entire channel is encrypted). Curator passwords are stored encrypted (SHA1) in the database (which is accessed directly by the Apache webserver).
Two potential vulnerabilities were identified by the security review. Both vulnerabilities were immediately corrected.
The OntoBrowser installation is vulnerable to Cross-Site Request Forging (due to the use of HTTPS Basic Authentication). To correct this vulnerability a general solution would need to be implemented based on the default method provided by GWT to eliminate XSRF attacks (for session cookies).