Top 10 Security Risks for 2013

The sections below identify the controls in the Oracle Healthcare Foundation API that are used or may be used to address the OWASP Top 10 security vulnerabilities. In some cases, the controls are integrated into the product and proper use of the controls by the client is required to validate the integrity of the controls.

• #1 - Injection
  
• #2 - Broken Authentication and Session Management
  
• #3 - Cross Site Scripting (XXS)
  
• #4 - Insecure Direction Object References
  
• #5 - Security Misconfiguration
  
• #6 - Sensitive Data Exposure
  
• #7 - Missing Function Level Access Control
  
• #8 - Cross-Site Request Forgery (CSRF)
  
• #9 - Using Components with Known Vulnerabilities
  
• #10 - Non-validated Redirects and Forwards
  

#1 - Injection

Injection vulnerabilities occur when data is sent into an interpreter via an interface specification and the party submitting the data does not check the data to ensure only the expected actions are performed by the interpreter on the data. SQL, Code, Command, Log, Path Transversal (XML) are all possible types of injection depending on the interpreter used in the container.

• Valid Content Types
  
• SQL Injection
  
• XML Injection
  
• LDAP Injection
  

Valid Content Types

The inbound provisioning REST service only supports the JSON data format. The service client must accept and send 'application/json' as the media type while invoking the REST service.

SQL Injection

To prevent SQL injections, the inbound provisioning REST API uses bind variables in SQL queries, which block SQL injection possibilities.

XML Injection

The inbound provisioning REST API accepts and generates only the JSON data format. Therefore, XML injections are not possible.

LDAP Injection

The inbound user provisioning REST API checks all incoming user input through a preset whitelist of allowed inputs and checks the pattern of the ultimate payload for any attack. However, custom code for protecting against LDAP injection at the client side it always welcome.

#2 - Broken Authentication and Session Management

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. The inbound user provisioning REST API uses BASIC authentication as the authentication mechanism.

#3 - Cross Site Scripting (XXS)

The Oracle Healthcare Foundation REST API mitigates cross site scripting by following the recommended methodologies listed on the OWSAP website. The best method to address XXS is to validate all data using whitelists and encode data as necessary given the presentation or headline of the data.

#4 - Insecure Direction Object References

When a developer exposes a reference to an object without proper access or other protection, this reference becomes an attack vector. When developing code and sending data to and from the API, make sure that the authorization model of the API interface is consistent to guard against insecure direction object references.

The authorization model in the SCIM interface protects down to the object level and the SCIM interface has been tested to validate proper authorization constructs within the functions of the defined service. Any client code built to integrate with the SCIM interface should complement this security model so that proper authorization is controlled at the object level.

#5 - Security Misconfiguration

Consult the product secure configuration document to ensure the product API is locked down properly.

#6 - Sensitive Data Exposure

Not all data is public and caution should be used to hide sensitive information from unauthorized users. Failure in security configuration and the selection of insecure defaults may pose a risk of data leakage.

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.

#7 - Missing Function Level Access Control

As a best practice, never assume that a specific method will only be called within the context that it was initially designed for. All access to functionality that manipulates data must be protected either by access control on the entity or by guarding the invocation of methods with the appropriate permission checks. The credentials of the identity associated with the access control at the client application must be encrypted and stored in a secure fashion.

#8 - Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery requires a browser container. In general, APIs are not meant to be supported directly in a browser container, so the session is not kept as a browser cookie and CSRF is not a viable threat.

#9 - Using Components with Known Vulnerabilities

The API stack is constantly updated with the latest security fixes and patches. Oracle recommends that developers using the API do the same.

#10 - Non-validated Redirects and Forwards

User Provisioning API responses do not provide URLs to other resources or sub-resources in the returned representations. Therefore, this API is not subject to this vulnerability.