Web application security is a core component of any internet-based business, and many times when writing software we don’t pay enough attention to security. This can have a negative impact on the whole business, or in the worst case, it can lead to the company’s demise.
Creating secure software requires adopting secure programming practices, but it is also important to implement culture changes to ensure that everyone in the company is aligned in creating products that offer great user experiences but are also safe.
What is OWASP’s Top Ten
The Open Web Application Security Project (OWASP) is a non-profit foundation that works to improve the security of software. Almost all of its members are volunteers and it is not affiliated with any technology company. Therefore, since there is no commercial pressure, it provides unbiased information about application security.
The OWASP Top 10 is a standard awareness document for web application developers and security. It represents a broad consensus on the most critical security risks for web applications.
Companies should adopt this document and begin the process of ensuring that their web applications minimize these risks associated with the OWASP top vulnerabilities. Using the OWASP Top 10 is perhaps the most effective first step in changing the software development culture within your organization to one that produces more secure code.
Here are some of web applications’ top common security risks and vulnerabilities.
Top 10 Web Application Security Risks
Importantly, the Top 10 is updated regularly and is made up of data coming from security vendors and consultancies, bug bounties, along with contributions from the organization. Compared to the last update, the 2021 version brings three new categories, four categories with naming and scope changes. Names have been changed to focus on the root cause rather than the symptoms.
A01 Broken Access Control occurs when an attack can access user accounts. The attacker could operate as a user or system administrator.
A02 Cryptographic Failures make an application vulnerable when encryption doesn’t work properly. This protection problem can also lead to the exposure of confidential data, both company and customers, or system structures, which are compromised without their access “filter”.
A03 Injection is an entire class of attacks that rely on injecting data into a web application to make it easier to unexpectedly execute or interpret malicious data.
A04 Insecure Design deals with security flaws that can be found in the software design, such as a password recovery flow including questions and answers, where more than one person may know the answer.
A05 Security Misconfiguration is an issue made during configuration that makes the environment or data vulnerable. For instance, when the directory listing is turned on in a Web server an attacker could list application directories and possibly access sensitive information.
A06 Vulnerable and Outdated Components such as libraries, frameworks, and other software modules can be defined as third-party applications or software/platforms that are out of date and contain bugs that are public to everyone.
A07 Identification and Authentication Failures are errors in identification and authentication thatwhich lead to vulnerabilities in the system, which become exposed to users and profiles that should not have access to certain information and actions.
A08 Software and Data Integrity Failures are related to software update issues, as well as CI/CD pipelines and critical data whose integrity is not properly verified. Insecure deserialization flaws also fall into this category, which can lead to remote code execution.
A09 Security Logging and Monitoring Failures include security flaws in commands and systems related to problem monitoring and failure prevention. They make an application susceptible to attacks that target any part of the application stack.
A10 Server-Side Request Forgeryis a vulnerability that allows an attacker to send requests on behalf of a server. During an SSRF, attackers forge the vulnerable server’s request signatures, allowing them access to internal services.
The workshop is structured in a way that for each security risk, two main elements help illustrate and address the issue:
They need to be exploitable by the user running the workshop (e.g. via postman), to replicate the problem.
They need to be testable so that we can have a failed and successful automated test, to illustrate this in the exercises.
In addition, the workshop has a step-by-step guide to run the exercises and also a slide deck explaining the theory.
At the end of each explanation, an activity is proposed to get your hands dirty in order to understand in practice how to exploit the vulnerability. It will make you think about and research the issue to find a suitable solution. At the end of the exercise, we show a plausible solution to the proposed problem.
Within each workshop module, there is a pre-configured Fastify server to demonstrate security issues and to run the exercises, you just need to have the following requirements installed:
Postman for testing requests
To run the modules, after cloning the repository locally you need to follow the following steps:
npm start to run the server
npm run verify to run automated tests against your solution to check if the security issue is resolved
Running an example
To better illustrate, let’s get down to business and run one of the exercises, which will be about Broken Access Control.
This vulnerability occurs when access to resources is granted by incorrectly configured restrictions so that users are allowed access to unauthorized functionality or data like other accounts, confidential documents, etc.
First of all, run the server for step 1 (cd src/a01-access-control, npm start). There is a Postman collection in the repository to help us run requests. After importing it, run the query for A01: Access Control and observe the data for Alice being returned.
Now change the username query parameter to bob and see the response:
Copy to Clipboard
We realize that Bob’s data is being exposed, and we’re logged in as Alice and shouldn’t see Bob’s data.
The next step is to run the automated tests for step 1 npm run verify. The tests will fail because the server shouldn’t return Bob’s data.
Then let’s edit the /profile route in the exercise folder to return only the logged-in user’s profile without exposing other people’s profiles.
💡 A good approach to solve this issue is by using fastify-jwt to handle authentication
The issue comes from the usage of a user-supplied query parameter to choose which profile’s info to check. The server should instead fetch only the logged-in user’s info and reply with 403 in other cases.
A recommended approach to solving the problem is to make the main part of the /profile endpoint request handler look like the code below:
If you are not already following and implementing mitigations for the top ten OWASP risks, we believe this workshop will be a great opportunity to get started!
In addition, the workshop will be useful to get hands-on experience on how to make applications secure against cyber-attacks, helping to potentially reduce the rate of errors and operational failures in systems.