Security Best Practices with Unity API

[Ramya_Kondeti]

Overview

Unity API is a powerful tool that can be used to extend the existing functionality of OnBase. It provides a robust set of operations that allows a user to store, retrieve and modify data in OnBase. As such care should be taken to protect that data from unauthorized disclosure, unauthorized use or modification or deletion via the API. Developer should keep in mind the security implications of the functionality exposed to the user and how it is going to affect the data. During the Discovery/Requirements Gathering phase, it is also important to gather the Security Requirements for the application and develop the application around those requirements.

While you can find a lot of articles in the internet talking about how to secure your application and what would be the best security practices to use while developing your application, we have put together a list of things that we encourage people to follow while developing an application using Unity API. This is not a comprehensive list of Security best practices but touches some of the important aspects of securing an application.

1. Always use SSL
 This helps to transmit your data securely. It is perfectly fine to turn it off in a test environment but NEVER in a production environment. This can be controlled via web.config with "AllowInsecureConnection" key.
2. Filter Exceptions
 Do not expose sensitive information via your exceptions. It is a good practice to filter OnBase or Custom exceptions before exposing them to the users. Use your judgement as to what to include in an exception message making sure that an attacker would not be able to use that information to launch any attacks or gain information that he/she is not supposed to.
3. Follow Least Privilege Rule
 Do not expose a functionality unless it is required. Expose the least possible actions that a user can perform using the application and expose more functionality on a need basis. This reduces your attack surface and prevents accidental or intentional damage to the data.
 Also the user using the application should have as few privileges as possible to perform only the necessary operations. So even if the account is compromised, the attacker would not be able to gain much.
4. No hard coded passwords
 Do not hard code passwords into the application. It is a good practice to authenticate every user that uses the application.
 Also, DO NOT store passwords in Configuration Items. Configuration Items and Connection Strings are used for defining strings that can be used in multiple scripts without declaring them everytime in each script. Though they can only be viewed/configured by an administrator, they can be used by any Unity Developer. So care must be taken not to disclose any sensitive information through them.
5. No direct queries against database
 Do not write queries directly against the database unless there is an exceptional situation that requires this. Queries aginst the data base are prone to SQL injections and OnBase has taken every possible care to prevent this in its data layer. In case you have to write queries, make sure to use parameterized queries, make sure that the variables are strongly typed,use least privileged account to connect to the database, close the connection as soon as possible, store the connection strings in a secure configuration file. Also, while it is valid to read data from DB directly, you are not supposed to modify the data without going through the proper channels first.
6. Log user actions
 OnBase does an extensive logging of all the actions performed against it. It is also a good practise to add custom logging on top of the existing one in your application.
7. Do not directly access diskgroups
 It is a bad idea to directly access files from diskgroups in your application.
8. Validate data
 Always validate data that comes from a user before doing anything with it. Use whitelists where ever applicable, validate for expected data types, validate length, valid data ranges, etc... While Unity API takes care of this for you, it never hurts to add an additional layer of security to the application.
9. Check permissions
 Use CanI method wherever possible to check for privileges before performing an operation.
 Unity scripts in workflow have different set of privileges. They generally bypass most of the privilege checks that Unity API generally does because of the Workflow's requirement. So it is up to the developer of the Unity Script to take extra caution and add necessary privilege checks before performing an operation via such scripts.
10. No idle connections
 Do not leave a connection idle for a long time. It holds a license and is also prone to attack.
11. Disconnect properly
 Always disconnect when the application is no longer in use. This ensures that the session is killed on the server and cannot be leveraged by an attacker to attack the system.
12. Upgrade to latest version
 We at Hyland strive to make our product secure and address any issues related to security as soon as possible. Hence it is always a good idea to upgrade to latest version whenever possible.
13. Do not process large requests
 Try to avoid processing large requests that takes up all the resources on the application server. This can be leveraged by an attacker to cause Denial of Service attacks.

Conclusion

    In the wake of new threats emerging everyday, it is extremely important to take every precaution to thwart those threats. We at Hyland do our best to address as many threats as possible in the Unity API, but it is also on the shoulders of the developers using the API to make sure that their application cannot be misused to gain sensitive information or modify/delete data from OnBase.

Next week we'll be talking about permissions, what OnBase checks, and what developers are trusted to check.