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.
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.
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.
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.
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.
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.
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.