Skip to content

Latest commit

 

History

History
87 lines (56 loc) · 9.02 KB

security_review.md

File metadata and controls

87 lines (56 loc) · 9.02 KB
Raw

Introduction

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.

Code Review

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)

Cross-Site Scripting (XSS) can generally be prevented by ensuring that all data (or dynamic content) rendered by the browser is rigorously escaped. The assumption is that any data or dynamic content can potentially contain malicious HTML or JavaScript. Therefore the application needs to be explicitly coded to escape all data (or dynamic content) so the browser does not potentially parse, interpret and/or execute malicious HTML or JavaScript (resulting in XSS).

In GWT applications, many aspects of a web-application's UI are expressed in terms of abstractions (such as Widgets) that do not expose a potential for untrusted data to be interpreted as HTML or JavaScript. As such, GWT applications are inherently less prone to XSS vulnerabilities. However, certain aspects of the GWT framework intentionally allow application developers to bypass the default GWT escaping mechanism and enable the browser to directly evaluate content e.g. enabling markup generated on the server to be rendered directly by the browser within a GWT application.

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.

The GWT framework also allows developers to embed native JavaScript (JNSI) within an application. Native JavaScript is interpreted directly by the browser and as such needs to be carefully inspected for XSS vulnerabilities. The OntoBrowser code includes three JNSI methods: one method to determine if the browser supports SVG and two methods for calculating the center of SVG (or VML) content for automatic scrolling purposes. After inspection of the JNSI methods, it has been confirmed that the methods do not create, evaluate or render markup or script (i.e. they are read-only methods) and hence do not expose any XSS vulnerabilities.

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:

  • createChildTerm
  • updateTerm
  • obsoleteTerm
  • addSynonym
  • updateSynonym
  • obsoleteSynonym
  • addRelationship
  • updateRelationship
  • obsoleteRelationship
  • approve
  • reject
  • delete
  • changePassword
  • excludeControlledVocabularyTerms

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.

HTML and JavaScript was entered in all input fields within the application GUI to tested that all user input was subsequently escaped when rendered by the browser.

Only one field (Term URL) was identified as a potentially security risk - using the javascript URL protocol (supported by all modern day graphical browsers) an attacker could inject arbitrary JavaScript code that would be run whenever any user clicked on the subsequent hyperlink (created from the Term URL user input).

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).

Conclusion

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).