2 Top ten security risks for 2017

• Overview of the OWASP top ten list
  
• #1 - Injection
  
• #2 - Broken authentication
  
• #3 - Sensitive data exposure
  
• #4 - XML external entities (XXE)
  
• #5 - Broken access control
  
• #6 - Security misconfiguration
  
• #7 - Cross-site scripting (XSS)
  
• #8 - Insecure deserialization
  
• #9 - Using components with known vulnerabilities
  
• #10 - Insufficient logging and monitoring
  

Overview of the OWASP top ten list

The listed security threats are probably the most severe threats and application developers have to be aware of and protect against these threats.

For more information, see the following:

• OWASP home page: https://www.owasp.org/index.php/Main_Page
• General descriptions for the OWASP top ten list of security risks for 2017: https://www.owasp.org/index.php/Top_10-2017_Top_10
• Overview of the security risks: https://owasp.org/Top10/

#1 - Injection

Injection vulnerabilities can occur when data is sent to an interpreter via an interface specification and the party submitting the data does not check the data to ensure that the interpreter performs only the expected actions on the data.

SQL, Code, Command, Log, Path Transversal (XML) are all possible types of injection based upon the interpreter used in the container.

• Valid content types
  
• SQL injection
  
• XML injection
  

Valid content types

The Oracle Clinical One Platform suite is a microservice-based application built on JAX-RS libraries and hosted in Oracle Life Sciences Cloud (also known as GBUCS).

Developers must use @Produces to handle different Content-Type. Also consider placing @Valid annotation for handling parameters during invocation itself.

SQL injection

The Oracle Clinical One Platform API passes different parameters as bind variables into the named queries, which makes SQL injection impossible.

XML injection

The Oracle Clinical One Platform Data API handles XML injections by using an XML parser library built within the core framework. During integration with other external systems, we recommend that you extend this XML parser library and verify if the definition or constraint for data type and length are accurately met.

#2 - Broken authentication

Risks associated with broken authentication and session management are often due to these functions not being implemented properly. As previously stated, custom authentication mechanisms should not be implemented and have not been implemented. Since the Oracle Clinical One Platform API works in a stateless manner, all inbound requests must either carry a valid JWT token, or perform basic authentication.

The JWT token is encrypted with the necessary algorithm, in accordance with security standards, and it carries the necessary information (expiry, user, principals) in its payload.

When using basic authentication, always transmit credentials over a secure channel.

Credentials are not stored or logged in the Oracle Clinical One Platform system at any point in time.

The Oracle Clinical One Platform API also performs fine-grained authorization for the user to ensure that only a user with the appropriate roles is allowed to access the REST web service endpoints.

#3 - Sensitive data exposure

Not all data is public and we advise that you hide any sensitive information from unauthorized users. Failure in security configuration and the selection of insecure defaults may pose a risk of data leakage.

Developers should use TLS 1.2 or above to consume the Oracle Clinical One Platform API to protect sensitive data and address Man-in-the-Middle attacks.

Web client developers should enforce encrypted data transport when the application transports sensitive data and should validate that all certificates are legitimate and signed by public authorities. Ciphers should be restricted to modern implementations.

#4 - XML external entities (XXE)

The Oracle Clinical One Platform API does not use XML for any kind of interaction. However, there is a JAXB implementation available within the core library where XML external entity support has been programmatically turned off as a precaution. We recommend that you implement a similar approach based on recommendations from the OWASP XXE Prevention Cheat Sheet.

#5 - Broken access control

All Oracle Clinical One Platform API endpoints enforce fine-grained authorization for the user, to ensure that only a user with the appropriate roles is allowed to access the REST web service endpoints.

#6 - Security misconfiguration

The Oracle Clinical One Platform suite is always installed in a secure-by-default state in the production environment. Default server users are disabled, and unused ports are blocked as part of deployment. Any communication to Oracle Clinical One Platform application servers happens through the Oracle Life Sciences IAMS, and the OHSIAMS WebGate monitors each API call for authentication details.

As part of standard protocol, black box testing is regularly carried out to detect any possible misconfiguration issues. Possible issues are addressed in either the source code or the infrastructure by applying critical patches.

#7 - Cross-site scripting (XSS)

Cross-site scripting occurs chiefly due to browser presentation of data. Input data to the Oracle Clinical One Platform API is always passed through an initialization request filter located within its core library. This filter looks for suspicious or harmful characters, and blocks requests if needed. All outbound responses are decorated with an X_FRAME_OPTIONS header to prevent clickjacking.

#8 - Insecure deserialization

The Oracle Clinical One Platform API validates all inbound requests and serializable objects at multiple levels. No data persists at the middle-tier level. In addition, Oracle Clinical One Platform is hosted within the GBUCS cloud, further reducing the chances of a remote execution scenario. Therefore, insecure deserialization scenarios are not applicable for users of the Oracle Clinical One Platform API.

#9 - Using components with known vulnerabilities

The Oracle Clinical One Platform technology stack is constantly updated with the latest security fixes and patches. We recommend that developers using the API maintain their technology in the same way.

#10 - Insufficient logging and monitoring

All Oracle Clinical One Platform API calls pass through authorization service filters. These filters log any kind of unusual or unexpected behavior, which is shown in the centralized Kibana dashboard. Active monitoring of unexpected events is very important to identify and notify of active attacks so that preventive measures can be taken to address advanced persistent threats (APTs).