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
Parent topic: Secure Development Guide
#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.
Parent topic: Top 10 Security Risks for 2013
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.
Parent topic: #1 - Injection
SQL Injection
To prevent SQL injections, the inbound provisioning REST API uses bind variables in SQL queries, which block SQL injection possibilities.
Parent topic: #1 - Injection
XML Injection
The inbound provisioning REST API accepts and generates only the JSON data format. Therefore, XML injections are not possible.
Parent topic: #1 - Injection
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.
Parent topic: #1 - Injection
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#5 - Security Misconfiguration
Consult the product secure configuration document to ensure the product API is locked down properly.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013
#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.
Parent topic: Top 10 Security Risks for 2013