Release 1.2.1
E76092-01
 Home |  Book List |  Contents |  Contact Us |
Go to main content
| Oracle® Health Sciences Identity and Access Management Service Secure Development Guide Release 1.2.1 E76092-01 |
|
| PDF · Mobi · ePub |
Secure Development Guide
Release 1.2.1
E76092-01
June 2017
This Secure Development Guide provides assistance in mitigating common security risks for developers using the Oracle Health Sciences Identity and Access Management Service (OHSIAMS) OHSIAMS Inbound User Provisioning Service API, developed based on the SCIM standard and REST framework.This guide describes how to prevent the main security risks, as identified by the Open Web Application Security Project (OWASP) in their top 10 critical web application security vulnerabilities for 2013, and provides insights for software developers into how the API was created and can be used while addressing these vulnerabilities.
Since in-depth defense is an important strategy for a secure product, do not exclusively rely on the techniques documented in this guide. Implement and extend these techniques in your own code as you develop your interface to the API specification.
Note:
The recommendations in this guide are not exhaustive and no guarantee is offered that implementing all the suggestions provides sufficient protection against all security threats. You cannot delegate responsibility for secure application development to a third party or a single document.The purpose of this document is to support developers in knowing the security tools and features that they can use to implement application security when using OHSIAMS APIs. This document does not replace a formal review process.
The Open Web Application Security Project (OWASP) publishes an annual list of the 10 most critical security vulnerabilities identified for the current year to educate developers on the security risks they most likely need to protect against. The OWASP top 10 vulnerability listing is technology agnostic and does not contain language or framework specific examples, explanations, hints, or tips.
The OWASP top 10 list for the year 2013 doesn't differ much from lists published for previous years, except for changes in ranking. The listed security threats are probably the most severe threats and application developers have to be aware of and protect against these threats.
Addressing these ten security vulnerabilities doesn't provide for total security, but it is a good starting point in preventing the current major security threats. This document explains how the OHSIAMS Inbound User Provisioning Service API addresses these potential security risks and how API developers should address these security vulnerabilities and risks when using the API.
General descriptions of the top 10 security risks identified by OWASP for 2013 are available at:
https://www.owasp.org/index.php/Top_10_2013-Top_10
You can get an overview of the security risk for an application at:
https://www.owasp.org/index.php/Top_10_2013-Risk
Go to Contents
The best way to ensure application security is through education. Developers and project leaders should be aware of security issues and secure coding practices. Training for these roles should include an in-depth explanation of the potential risks, as well as cover the features of the development and deployment platforms that help mitigate exploits.
The most important design principle for application security is to implement security by design and by default. Secure coding guidelines should be made available, adhered to, and enforced in all development organizations, irrespective of the tools and platforms being used.
An example of security by default is the behavior of elevators in case of a power outage. Instead of releasing the breaks, we expect elevators to apply the breaks for the safety of passengers in the cabin. The elevator applies the brakes because this was defined as the default behavior.
So, before thinking about how to prevent external attacks, identify secure defaults for an application that can protect it from the inside. This, however, does not work well without training and awareness.
Go to Contents
Developers don't always immediately identify the security measures they need for an application within the security toolset provided by a platform or built into a framework. As a result, "build your own security" is not uncommon among development projects. This is especially true if the application is a replacement of an existing system that uses its own non-standard security infrastructure. An example for this is database based authentication and authorization in combination with user provisioning and granting access to resources at runtime.
The risk associated with building your own security is that you are also responsible for quality assurance of the security layer, application security propagation and single sign-on, as well as bug fixing and maintenance of the security layer. Not all developers are security experts, but experts are a necessity to build a custom security layer.
We recommend allocating time to investigate and implement existing, well vetted security solutions. Applying existing solutions to custom applications may be easier and more cost-effective than creating custom mechanisms that may offer less protection in their incipient phases.
Go to Contents
The below sections identify the controls within the Oracle Health Sciences Identity and Access Management Service OHSIAMS Inbound User Provisioning Service API that are used or may be used to address the top 10 security risks identified by OWASP for 2013.
In some cases, the controls are part of the product and proper use of the controls by the clients is required to validate the integrity of the controls.
The following risks are considered:
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 that only the expected actions are performed on the data by the interpreter.
Injections of the type SQL, code, command, log, path transversal (XML) are all possible, based on the interpreter used in the container.
The REST service of the OHSIAMS Inbound User Provisioning Service supports only the JSON data format. The service client must accept and send 'application/json' as the media type when invoking the REST service.
To prevent SQL injections, the OHSIAMS Inbound User Provisioning Service API uses bind variables in SQL queries.
XML injections are not possible because the OHSIAMS Inbound User Provisioning Service API accepts and generates only JSON data format.
The OHSIAMS Inbound User Provisioning Service API checks all incoming user input through a preset whitelist of allowed input and checks the pattern of the ultimate payload for any attack. Although we generally do not recommend making use of custom code, you can further enhance protection against LDAP injections through custom code on the client side.
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. They have not been implemented for the OHSIAMS Inbound User Provisioning Service API, which uses a BASIC authentication mechanism. The session is created on request and destroyed at the end of the response. Each API request must be accompanied by BASIC authentication headers to prevent session hijacking.
The OHSIAMS Inbound User Provisioning Service API prevents cross-site scripting by following the OWASP recommended methodologies.
The best method to address XSS is to validate all data using whitelists and encode data as necessary, according to the presentation or handling of the data.
When a developer exposes a reference to an object without proper access or other protection, this reference can become a means of attack. When developing code and sending data to and from the API, ensure that the authorization model of the API interface is consistent to guard against insecure direction object references.
The authorization model in the SCIM interface ensures protection down to the object level and the SCIM interface has been validated for proper authorization constructs within the functions of the defined service. Any client code built to interact with the SCIM interface should complement this security model so that proper authorization is controlled at the object level.
Since OHSIAMS is hosted in the Oracle Cloud for Industry (OCI) environment, its services adhere to the OCI policies, as described here. Clients of the OHSIAMS API should implement similar security and available polices to ensure the confidentiality, integrity, and availability of data flowing through the interface.
We recommend hiding sensitive information from unauthorized users and handling sensitive data securely. Failure in security configuration and selecting insecure default settings may facilitate 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. Also, ciphers should be restricted to modern implementations.
As a best practice, do not assume that a method will only be called within the context for which it was initially designed.
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 credential of the identity associated with the access control at the client application must be encrypted and stored securely.
Cross-Site Request Forgery requires a browser container. Generally, APIs are not meant to be supported directly in a browser container, meaning that the session is not kept as a browser cookie and CSRF is not normally a threat.
To further prevent any CSRF attacks, the OHSIAMS Inbound User Provisioning Service API does not render any content in HTML and forces the browser to download the response as an attachment.
The technology stack for the OHSIAMS Inbound User Provisioning Service API is constantly updated with the latest security fixes and patches. Oracle recommends that developers using the API do the same on their end.
OHSIAMS Inbound User Provisioning Service API responses do not provide URLs to other resources or sub-resources in the representations that are returned, thus this API is not subject to this vulnerability.
Go to Contents
Application security is ineffective if the application itself runs in an insecure environment. Perimeter security describes the levels of protection that are added on servers, the network, and other data access channels outside of the API domain and should also be considered to ensure thorough prevention of security risks.
As can be seen in this document, not all of the OWASP top 10 security vulnerabilities for 2013 are relevant for application developers, depending on the implementation.
Go to Contents
We recommend that you familiarize yourself with the content available on the OWASP website:
https://www.owasp.org/index.php/Main_Page
Go to Contents
For more information, see the Oracle Health Sciences Identity and Access Management Service Inbound User Provisioning API Guide on the Oracle Help Center.
Note:
Always check theOracle Help Center to ensure you have the latest documentation.Go to Contents
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
Oracle Health Sciences Identity and Access Management Service Inbound User Provisioning Service API Guide, Release 1.2.1
E76092-01
Copyright © 2014, 2017, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.