blog heading image

Overview

In a previous article, we’ve discussed adherence to HIPAA standards and how we can and should meet security requirements with every solution we design. Inevitably you’ll ask yourself “How do I know my application is secure enough without exhaustive testing on all vectors?” You should still do penetration tests and hire experts to ensure your solution is secure. There are no shortcuts to avoid best practice penetration testing and cybersecurity auditing. However, architecting with well-documented publications and standards is an efficient way to fix the problem before it has a chance to occur. Leading the way are two well-established organizations the National Institute of Standards and Technology (NIST), and the Open Web Application Security Project (OWASP). Following these guidelines is a great first step to ensuring that your application is secure to the highest standards and that your users are protected. There’s a lot of reading material for a rainy day, for now, we’ll focus on OWASP TOP 3 and mechanisms to mitigate the vulnerabilities.

OWASP Foundation, the Open Source Foundation for Application Security |  OWASP Foundation

OWASP

History

The OWASP foundation was launched on December 1st, 2001, to improve software security through open communication, tools, documents, and community-led open-source projects. Don’t let the name fool you since its inception OWASP has branched out from strictly web-based applications to provide security standards and examples for mobile applications and even embedded development best practices. As a non-profit organization, they provide many open-source samples, documents, global and local events, and training.

TOP 3

At a minimum, all projects should mitigate the risks outlined in the OWASP Top 10. These rankings are updated periodically with the last update in 2021 as items become prevalent. An example of an item becoming less prevalent is the previous number two A2:2017 Broken Authentication shifting to number seven due to the wealth of frameworks available for authentication. Frameworks such as Auth0 or those offered by AWS, GCP, etc. provide authentication as a service alleviating you from worrying about writing your authentication layer. Here are the OWASP top three with some mechanisms to mitigate the outlined risks.

A1:2021 Broken Access Control

The new number one is broken access control allowing users access to resources and services they should not have access to. It’s important to have a strategy around access using the principle of least privilege (PoLP). PoLP requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources necessary for its legitimate purpose. The last thing you want is for every developer to be an admin on your AWS because this can increase the chance of breach and may allow misuse of critical systems.

Concern Mitigations
  • Violation of the principle of least privilege or denial by default
  • Access should be on an as-needed basis
  • Specifically in your cloud services permissions list there should be an established hierarchy and separation of services with team members having access to only the services they need to interact with

Concern Mitigations
  • Bypassing access control checks by modifying the URL, application state, web page, or by modifying API requests.
  • Permitting viewing or editing someone else's account, by providing its unique identifier (insecure direct object references)
  • Accessing API with missing access controls for POST, PUT, and DELETE.
  • Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
  • Force Browsing to secure areas by manipulating URL schemes
  • Ensure that URL and API access is locked down through permissions on the resources that need to be accessed. A user shouldn’t be able to modify a URL parameter to get access to someone else’s data. Each request needs to verify that the user making the request has permission to do so
  • Disable web server directory listings to ensure that no one can see the entirety of the site map
  • Do not include git files or other unnecessary files to be included in deployments
  • Establish the user types according to least privilege with each request checking the permissions of the user requesting before any operation is performed
  • Log access control failures to disable accounts that are suspected of nefarious activity
  • Ensure that sessions are properly invalidated so that users can’t simply utilize a previous session to give themselves a higher access level. This is technically a crossover utilizing a deficiency of A7:2021 to cause A1:2021
  • Ensure that session IDs do not contain sequential and thus easily perpetrated numbers. Ensure that pages are controlled via permissions according to the logged-in user
Concern Mitigations
  • Disallow communications from HTTP origins which are not verified origins
  • Best practice is to whitelist those domains that are allowed to perform CORS actions. Don’t allow everything through unless your website contains no secure data (“Access-Control-Allow-Origin: *”)

A2:2021 Cryptographic Failures

The Role of Cryptography Then and Now

The most common data exposure flaw is simply having no encryption to protect data, data needs to be encrypted at rest and in transit. Additionally, precautions need to be made to ensure that data is stored and passed as needed. More detailed in the following table.

Concern Mitigations
  • Misclassification of data leads to sensitive information being sent unnecessarily
  • Data needs to be classified as sensitive according to privacy laws (such as HIPAA), regulatory requirements (FDA), or business needs
  • Sensitive data should only be sent as needed and should always be encrypted

Concern Mitigations
  • Data in transit is not properly encrypted allowing Man in The Middle (MiTM), eavesdropping, and tampering with data
  • TCP communications over the internet must utilize the HTTPS protocol with TLS 1.2/1.3 and FIPS-based ciphers without the ability to fall back to lesser SSL which can result in POODLE or DROWN attacks.
  • Establish a chain of trust-based certificates between devices to prove the authenticity of communicating devices
  • On open systems, application-level encryption using FIPS-based ciphers
  • Ensure Certificates are from a trusted source and kept up to date. There are many certificate authority providers such as Entrust and DigiCert
  • Avoid decrypting sensitive data when retrieving from the database
Concern Mitigations
  • Data at rest is not encrypted allowing malicious users to read secure information.
  • Utilize cloud service providers that supply Database systems that encrypt the data at rest. These provide the additional benefit of secure hosting practices that often on-premises services do not have.
  • Utilize an enterprise-level database that provides provisioning for encryption at rest such as:
    • MySQL Enterprise
    • MSSQL
    • Couchbase
    • MongoDB Atlas
  • Encrypt passwords using a hashing mechanism such as Bcrypt. Bcrypt is a popular solution for one-way password hashing to ensure once passwords are stored, they can’t ever be read.

A3:2021-Injection

This refers to the use of nefarious parameters used to run commands directly into an SQL, NoSQL query, ORM, LDAP, Expression Language (EL)or Object Graph Navigation Library (OGNL). These attacks seek full access to the data by injecting extra characters into the interpreter to perform a different action than the original call. Consider an example for SQL Injection where you have an HTTP request that logs in a user with a username and password.

<span class="richtext-chip">SELECT * FROM users WHERE email = ‘antman@mail.com’ andpassword = ‘ClamCarivan’ </span>

<span class="richtext-chip">Or instead, you could modify your username parameter byadding in a - - </span>

<span class="richtext-chip">SELECT * FROM users WHERE email = ‘antman@mail.com’- -  AND password =’ ‘ </span>

<span class="richtext-chip">The user has now logged in with the admin user without usinga password because the AND has been escaped by using the - - comment syntax! </span>

One of the easiest ways to handle SQLi is to make sure you validate all parameters that are passed to the backend to ensure they’re of the expected form (input sanitization). In the case above validating that the passed-in email is of proper email format would fail because .com- - is not a valid email domain. Granted not all parameters are as easy to validate as the email above, and thus validating the input is not always feasible. In addition to input sanitization, query parameters should utilize the interpreters’ escape character to ensure that extra characters are ignored.

Consider using an Object Relational Mapper (ORM) such as Sequelize. Sequelize and many ORMs attack the problem at the heart of SQL injection by escaping the properties inserted into your raw queries or escaping the properties in the queries generated by your data base calls. This way the queries are terminated to disallow the extra characters to perform malicious queries.

Closing

As the world moves to the cloud, security becomes paramount for every application.  Before you’ve puta single line of code down ensure that your architecture adheres to the standards put forth by OWASP and NIST. I’ve outlined some mitigation strategies and some that come with using services by well-established providers such as AWS, GCP, and Azure, or other libraries such as Bcrypt and Sequelize ORM. If you have an existing application, you owe it to your users to perform a self-audit to ensure that you’re following best practices to thwart cybersecurity attacks. This isn’t a one-time activity, we need to be consciously self-auditing because the hackers aren’t sleeping, and neither can we. Start with the OWASP top three, proceed to the top ten, and if you’re in the medical space don’t stop until you’ve left every stone between OWASP and NIST unturned.

Learn about our Software Engineering expertise and capabilities

Visit Page ➡

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.