Any good developer knows that security, especially in web applications, is an ever-changing field and it’s important to keep up to date. It’s also a complex field, so you should never try “rolling your own” security, and instead make sure to use industry standards and guidelines for the best possible security outcomes. In the fast-paced world of the financial markets, security is paramount, and all Sinara applications (web-based or otherwise) have to go through a rigorous development lifecycle where security is a key aspect at each stage, from requirements analysis, through implementation, testing and deployment.
One of the most useful industry resources for web security that we use at Sinara is OWASP. In this blog post, we’re going to look at what OWASP is and what resources they provide. We’ll also look specifically at the OWASP Top 10, perhaps the most well-known of all OWASP’s projects, and used regularly by all Sinara developers.
What is OWASP?
OWASP (the Open Web Application Security Project) is a non-profit organisation dedicated to improving software security worldwide. They have members and local chapters all around the globe, lead conferences and educational events, and have several projects which developers can use to make sure their systems are secure. Some of these projects produce tools and utilities, like the Zed Attack Proxy penetration testing tool, but many of them are focused primarily on documentation, producing standards and guidelines that can be applied to your web project from the very start.
The OWASP Top 10
If you reference just one piece of documentation from OWASP, the Top 10 should be it. The Top 10 is an awareness-raising project highlighting the ten most common and most dangerous security flaws found in web applications – and how to fix them! The Top 10 is updated every few years, with the current version being from 2021.
Of course, attacks on website security are constantly evolving, with new vulnerabilities being found all the time. However, the Top 10 can be a handy guide for considering how to secure a website – understanding the major risks that impact web applications allows us to proactively defend against them. It’s important to always be on the lookout for these common flaws, whether developing new websites or updating existing ones.
In the sections below, we’ll look briefly at each of the 2021 Top 10.
A01: Broken Access Control
The Broken Access Control category covers a wide range of vulnerabilities which all boil down to a simple problem: someone can do something they shouldn’t be allowed to do. This includes unauthenticated users getting access to pages that you ought to be logged in to see, non-admin users getting access to admin functions, and so on. There are many ways an attacker can achieve this, depending on the technologies used, so it’s important for applications to properly implement access controls, and default to denying access if they’re not sure whether a user should be allowed to do something.
A02: Cryptographic Failures
In previous iterations of the Top 10, this category was called Sensitive Data Exposure, which is one of the most common symptoms of a cryptographic failure. This flaw covers things like not using secure protocols when transferring or storing data, not enforcing HTTPS on web pages, and using out-of-date cryptographic methods like MF5 and SHA-1 hashing, which are known to have been cracked.
To defend against injection attacks, you should assume that no data provided by the user is to be trusted; it should always be validated on the server, and should never be passed in a “raw” form to something that might interpret it as code.
A04: Insecure Design
This category is an interesting new addition in the 2021 Top 10, focusing less on security vulnerabilities in the implementation of an application, and more on design and architectural flaws which would be insecure no matter how the developer builds them. This represents a “shift left” in the industry to try and catch problems earlier in the software lifecycle.
An example of insecure design might be a system which has been specified to use “security questions” for account recovery; these are known to be an unreliable way of verifying account ownership, and will be insecure no matter what is done at the coding stage.
A05: Security Misconfiguration
Like Insecure Design, Security Misconfiguration is a category which sits outside of the traditional “development” activities of software engineering, this time in the other direction, in the deployment and management of software after it has been built. This category covers a variety of vulnerabilities which may be introduced by misconfigurations of the software or the environment in which it sits, such as leaving default accounts and passwords set up, leaving developer features turned on which provide detailed error messages, and failing to set appropriate values for security settings. Given that we often do a lot of work at Sinara helping our clients with deploying complex systems, this is an area of high focus for our support team.
A06: Vulnerable and Outdated Components
As we noted at the start, security is a fast-moving field, with new exploits being discovered all the time. If you don’t have a process for keeping on top of the latest developments, you risk becoming vulnerable, no matter how well your developers might be building the software itself. It’s important to keep all your system components up to date, as well as the libraries and frameworks they depend on, and the platform on which it runs.
A well-known example of this is the Heartbleed vulnerability in OpenSSL, which was patched in April 2014; anyone running an older version of OpenSSL will still be at risk from the exploit.
A07: Identification and Authentication Failures
This category is all about making sure your users are really who they say they are. There are many attacks which focus on gaining access to a user account, including brute forcing (trying lots of passwords until one works), reusing stolen authentication tokens, exploiting weak password recovery processes, and so on. In general, the latest recommendation is always to use multi-factor authentication where possible (getting users to enter a code from an authenticator app on their phone), but there are also other defences which can help in this area, such as preventing users from using passwords known to be very common, rate limiting access to key pages like the password recovery page, and increasing the amount of time the user must wait after getting their password wrong. Interestingly, it is no longer recommended to lock user accounts after too many failed attempts – as this can become a vector for denial-of-service attacks.
A08: Software and Data Integrity Failures
This is another new category for the 2021 Top 10, reflecting the widespread use of CI/CD pipelines in modern development, as well as the use of dependency repositories such as npm. It’s important to make sure that you have confidence in all your dependencies – both that they are vulnerability-free, and that the binaries in use in your application are actually what you think they are.
A09: Security Logging and Monitoring Failures
Another category relating to management of the deployed software, Security Logging and Monitoring Failures comes from the community survey part of the OWASP Top 10, which is to say it’s been highlighted by industry professionals as a dangerous issue, rather than by purely statistical analysis. In short, it’s important that your software logs suitable warnings when attack-like events happen – for example, logging failed login attempts – and it’s also important that you have processes in place for alerting on and escalating that logging, so that when a breach occurs you can respond in a timely manner.
A10: Server-Side Request Forgery
The final category in the 2021 Top 10 is another new entrant, also raised from the community survey. This category is narrower than many of the others, though still obviously important, and covers vulnerabilities introduced when systems fetch data from a user-supplied URL without validating the URL. Attackers might use this to, for example, expose data from a URL that they would not normally be able to access (but which the application server can reach).
Other OWASP Projects
As mentioned above, the Top 10 is one of the most well-known OWASP projects, and it’s a good starting point for introducing security standards into a web application. However, it’s far from the only useful resource provided by OWASP.
A key resource I recommend to all developers is the OWASP Cheat Sheet Series. This is a series of simple, good-practise guides for developers, so that you can proactively build security into applications from the get-go, rather than waiting to encounter vulnerabilities like the ones in the Top 10. There are over 50 topics covered here, including general topics like authentication, authorisation and error handling, as well as specific technologies such as Docker, .NET, Java, LDAP, and so on. At Sinara, we cover all these topics at regular internal software engineering seminars to make sure our developers are up-to-date on best practices.
Some other OWASP projects include:
- Top 10 Proactive Controls – another “top 10” awareness-raising project, this time focused on security techniques to include in development projects proactively, rather than things that can go wrong
- Application Security Verification Standard – a set of recommended standards for verifying the security of an application, which is an excellent set of concrete requirements for calling an application “secure”
- Web Security Testing Guide – best practises for testing a web application for security flaws and vulnerabilities, handy for QA analysts and penetration testers
In conclusion, whether you already have mature processes in place for ensuring good security in your web applications, or are just starting out on a project and want to make sure it’s as secure as can be from the get go, OWASP is an incredibly valuable resource for anyone involved in software development.