Application Security Best Practices

The following post highlights best practices surrounding application security. These have been adapted from SANS and touch on general development and integration practices. These are the same recommendations that I use and make to developers in my everyday role when they want to create apps and also connect them to other systems. I have made these recommendations as broad as possible so that they can apply to a majority of industries.

The following provides an easy-to-reference set of best practices that raise awareness and help development teams create more secure applications.

• Error Handling and Logging
• Data Protection
• Authentication
• Input and Output Handling
• Access Control
• Session Management 

Error Handling and Logging

Display Generic Error Messages

• Error messages should not reveal details about the internal state of
  the application.
  • For example, file system path, user id’s and stack information should not be exposed to the user through error messages.

Log Access to Sensitive Data and Store Securely

• Logs should be stored and maintained appropriately to avoid
  information loss or tampering by intruders
• Any access to sensitive data should be logged.
  • This is particularly important for corporations that have to meet regulatory requirements like HIPAA, PCI, or SOX.
• If applicable, any authentication activities, whether successful or not, should be logged.

Data Protection

Use HTTPS everywhere (transmitting data securely)

• Ideally, HTTPS should be used for your entire application.
  • If you have to limit where it’s used, then HTTPS must be applied to any authentication pages as well as to all pages after the user is authenticated.
  • If sensitive information (e.g., personal information) can be submitted before.

Implement Strong password policy and reset system (if not using SSO)

• If applicable, a password policy should be created and implemented so that passwords meet specific strength criteria.
• If applicable, additionally, any password reset option must not reveal whether or not an account is valid, preventing username harvesting.

Store user passwords securely (if not using SSO)

• If the app would allow for password authentication (thus apps that are not utilizing SSO with connecting system) user passwords must be stored using secure hashing techniques with strong algorithms like PBKDF2, bcrypt, or SHA-512.

Limit the use and storage of sensitive data

• Conduct an evaluation to ensure that sensitive data elements are not being unnecessarily transported or stored.
  • Where possible, use tokenization to reduce data exposure risks.
• Make sure that URLs posted to athenaNet do not have exposed patient data on it that can be used publicly without authentication.

Authentication

Do not hardcode API credentials

• Never allow credentials to be stored directly within the application code.
  
  • While it can be convenient to test application code with hardcoded
    credentials during development this significantly increases risk and should be avoided.
• It is highly recommended to not check the key and secret into your codebase.

Store API credentials securely

• The best practice for a production deployment is to maintain the key and secret in a centralized place (a key server).
• The key server is responsible for calling the OAuth endpoint and getting and caching (until expiration) the access token.   
  • It should then make that token available for any callers in your environment who need to make an API call.

Input and Output Handling

Conduct contextual output encoding

• All output functions must contextually encode data before sending the data to the user.

Validate the source of output (Pulling data from athenaNet)

• Make sure the correct information needed is being pulled (correct appointment, patient info, etc )

Validate the source of input 

• Before submitting data into an application, make sure that data has been validated and sanitized to maintain integrity.
• Take measures to ensure that duplicate information are not being created. 

Access Control

Apply the principle of least privilege

• When an account is created, rights must be specifically added to that account to grant access to resources.

Don’t use un-validated forwards or redirects

• Avoid using simple/naked URLs that can allow an attacker to access private content without authentication.

Session Management

Re-generate access tokens

• Tokens should be regenerated when the user authenticates to
  the application and when the user privilege level changes.

Implement an idle session timeout

• When a user is not active, the application should automatically log the
  user out.

Implement an absolute session timeout

• Users should be logged out after an extensive amount of time
  (e.g., 4-8 hours) has passed since they logged in.
  • This helps mitigate the risk of an attacker using a hijacked session.

Place a logout button on every page

• The logout button or logout link should be easily accessible to users on
  every page after they have authenticated.
• When the user logs out of the application, the session and
  corresponding data on the server must be destroyed.

Set the cookie expiration time

• The session cookie should have a reasonable expiration time.
  Non-expiring session cookies should be avoided.