OWASP Security Threads/Vulnerabilities Report

The following report details the OWASP top 10 list for the most common web application security risks in 2021. The report will go into what the security is, the consequences of the security risk and the effect the security risk has on our application including measures taken to prevent or mitigate the security risk.

1. Broken Access Control

Broken Access Control refers to a vulnerability whereby a user can access or perform an action outside of their intended permission. As a result, this vulnerability can lead to unauthorized disclosure of information and a user performing an unauthorized action such as modifying or deleting data.

To mitigate this security risk the following preventative measures have been implemented:

• All functions that require authentication are denied by default. The JWT token must be authenticated for these functions to proceed.
• For the assignment we used MongoDB accessed via Atlas over the Internet. This was done as learning opportunity and was authorised by the supervisor (Reza) at the very beginning of the project. If this were a real commercial product, we would have utilised Amazon’s DynamoDB commercial service which can communicate with Lambda functions via a Virtual Private Cloud (VPC). This routes calls to the database over Amazon’s internal network infrastructure rather than passing the calls over the public Internet.
• Each back-end REST end-point handles a single function after authentication. This limits the scope of each function to its intended specific purpose and helps to prevent any leakage of information via an API call.
• All the back-end gateways end-points on Amazon are protected with SSL encryption.
• Parameters for the Lambda functions are held as environmental variables in AWS, while the database credentials are held in the Lambda Layer that is deployed to AWS. Credentials could be further protected using Amazon Secrets, a commercial product that acts as an encrypted store for holding sensitive information.
• The front-end files are deployed to a secure container running on Vercel. All access is via SSL encrypted links and Vercel also encrypts all secrets at rest and in transit while offering extended services such as DDOS protection when using the professional plans. (https://vercel.com/security)
• Rate limiting is set in the AWS API gateway. The current default setting is 10000 request per second with a burst of 5000 for the production gateway, but this could be limited according to the load generated in a commercial environment.
• Local data is deleted when the user logs out and a new JWT token needs to be generated at login. The lifetime of the JWT token is currently set as 7 days, but could easily be set to any value that achieves an acceptable balance between usability and security.
• Each user must validate their email address by clicking on link that is emailed to their supplied email address. Users are set to inactive by default when registering and cannot login without successful email validation.

2. Cryptographic Failures

Cryptographic Failures is a vulnerability where the cryptography used by an application fails to securely encrypt and protect sensitive data. A cryptographic failure can occur when data is stored or transmitted in plain text or a weak encryption is used to protect the data. As a result, this can lead to the exposure of sensitive data such as passwords, credit card numbers, and personal information.

To mitigate this security risk the following preventative measures have been implemented:

• The application now has end-to-end encryption where all messages are stored in the database in encrypted form. The key to decrypt the message must be decrypted by each channel member’s private key in order to reveal the message.
• Messages are transmitted in encrypted form, and decrypted on the client using the client’s password which is only stored in hashed format on the server. The server cannot decrypt the messages.
• Keys used to decrypt the messages are stored on the local device only and deleted when the user logs out. The keys are regenerated after successful login.
• Both the back-end API and the front-end are transferred in a HTTPS tunnel as managed by Amazon and Vercel.
• The JWT token uses a 64-byte hex string as a secret.
• Passwords are SHA512 hashed with a 16 byte salt using 2048 iterations.
• YaMa’s End-To-End encryption is based on AES-256 Encryption. AES is an Industry standard and is adopted by institutions that have an inherent interest in protecting encrypted data such as the US Government and European Union.
  • AES-256 is currently virtually impenetrable using brute-force methods on current computer hardware.
• YaMa’s encryption library is subtle crypto which is based on the Web Cryptography API. The Web Cryptography API is the current encryption standard for most modern browsers and all major modern browsers provide supports and are contributors to the open source project.

3. Injection

Injection refers to a vulnerability whereby an attacker supplies untrusted user input data which is then executed by the application as part of a command or query. Some of the most common types of injection attacks include SQL injections, cross-site scripting (XSS) and code injection. As a result, this vulnerability can lead to unauthorized disclosure of data, destruction of data, loss of data integrity and denial of service.

To mitigate this security risk the following preventative measures have been implemented:

• User credential input is validated on the front-end and the back-end before being stored in MongoDB.
• Svelte (the front-end framework we are using), treats all strings as plain-text by default and does not parse any code entered within a message.
• As MongoDB is a No-SQL database, any form of SQL-Injection attack is completely mitigated.

4. Insecure Design

Insecure Design refers to a vulnerability associated with the design or architecture of an application. Insecure design should not be confused with an insecure implementation. A vulnerability found in an insecure design cannot be rectified by a perfect implementation.

To mitigate this security risk the following preventative measures have been implemented:

• The cryptographic functions used in the application utilise well supported and secure libraries. We used the “crypto” and “jsonwebtoken” NodeJS libraries for hashing and authentication token management respectively, and the standard “crypto” browser library to implement end-to-end encryption.
• The entire application was developed with robust validation and authentication from the very beginning.
• The user that creates a group or channel is set as the administrator. Only administrators can modify the parameters of the group or channel including kicking or inviting additional users. This is validated in the front-end and re-validated in the MongoDB functions executed in the back-end.

5. Security Misconfiguration

Security Misconfiguration is a vulnerability where the security components within an application are left insecure or misconfigured. A security misconfiguration has the potential to allow an attacker to gain unauthorized access to the application’s data and functionality which can lead to the whole application system being compromised.

To mitigate this security risk the following preventative measures have been implemented:

• The development environment can easily be replicated with each user having to set their access credentials in order to deploy.
• The CI/CD pipeline we used centres around pushing code to GitHub which triggers front-end deployment to Vercel, while the back-end is tested and deploying to AWS using SAM. Pushing to GitHub, and deployment to AWS requires individual developer authentication.
• The repository that has been used in GitHub is private and accessible by authorised members of the team only.
• The secrets required for automated deployment to Vercel via a GitHub action are held as encrypted secrets in GitHub.
• Access to the Amazon backend and automated deployment via SAM is restricted to users that have a registered access key Id and a valid secret access token. Access can also be secured by multi-factor authentication.
• User rights in AWS have been restricted to only the services used by the application using Amazon Identity and Access Management (IAM).
• MongoDB Atlas access is restricted to authorised members of the team.
• Access to upload to S3 buckets (where the audio is stored) uses a unique pre-authorised link with a time-limited authentication token that is generated at time of recording. Once the token expires (set to 1 minute), the link can no longer be used to upload data.
• Only required frameworks have been included in the code.

6. Vulnerable and Outdated Components

Vulnerable and Outdated Components refers to a vulnerability whereby a component used by the application is either out of date, no longer supported or vulnerable to a known exploit. This vulnerability can lead to attacks that target both client and server-side components. As a result, an application would become more susceptible to attacks if it is using components that are out of date with a known flaw or vulnerability.

To mitigate this security risk the following preventative measures have been implemented:

• The GitHub repository we used has been set to enable Dependabot scanning. The code is automatically scanned for vulnerabilities periodically, with alerts being sent to team members if an issue is found, and a Pull Request automatically created if a solution is known.
• On top of this, we also use Snyk (https://snyk.io/) that we use to scan the code for vulnerabilities. Snyk has the convenience of both a web interface, and a Visual Code plugin to examine issues found in the code-base.
• We ensured that for all End-to-End encryption components, we used the most secure and modern methods possible to ensure that the End-to-End encryption lasts the longest possible time before modern computing components and methods catch up.

7. Identification and Authentication Failures

Identification and Authentication Failures refers to a vulnerability whereby the application’s functions relating to confirming a user identity, authentication, and session management is not properly protected or correctly implemented. As a result, this can lead to automated attacks such as credential stuffing or a brute force attack in order for an attacker to assume another users’ identity.

To mitigate this security risk the following preventative measures have been implemented:

• We have not implemented MFA for this project, however, all user passwords require a minimum of 8 characters, and requires the use of lower and upper case letters, numbers, and special characters.
• User emails are also verified before they can login.
• There are no default passwords or credentials used.
• Password recovery sends a link to the validated email address recorded in the database with a time-limited token. To change the password, the user must click this link to set a new password.
• Authentication tokens are generated every time the user logs into the application, and are currently valid for 7 days but can be limited to any length desired.

8. Software and Data Integrity Failures

Software and Data Integrity Failures refers to a vulnerability associated with using code or infrastructure without verifying its integrity. This vulnerability can occur when an application uses software from an untrusted source or software that has been manipulated at the source and is subsequently downloaded without checking for code integrity.

To mitigate this security risk the following preventative measures have been implemented:

• A limited set of trusted libraries have been used for the application.
• The use of Svelte to generate a reactive front-end means that the code is compiled to vanilla JavaScript before deployment.
• Both GitHub Dependabot and Snyk are employed to scan the code and dependencies for vulnerabilities.

9. Security Logging and Monitoring Failures

Security Logging and Monitoring Failures is a vulnerability that focuses on the failure of an application system to properly monitor and maintain security logs. By not having an adequate logging system to log, monitor, or report suspicious activity such as failed login attempts the likelihood of a successful attack by an attacker increase.

To mitigate this security risk the following preventative measures have been implemented:

• AWS logs all Lambda activity in the back-end to a service called “CloudWatch”. This enables all activity and system utilisation to be monitored, with the ability to set actions that are triggered by events or other services within the AWS ecosystem.
• The logs are secured with authentication by AWS, and access can be restricted by user or user group.
• AWS can be easily configured for replication, redundancy and fault tolerance in a commercial situation for a price.
• Different gateway end-points can be utilised in different geographic locations, while the Lambda functions are scaled based on utilisation.
• MongoDB also utilises clusters and can have replication and backups in the professional-grade tiers.
• Vercel offers commercial plans that enable scalability and enhanced protection if required.

10. Server-Side Request Forgery

Server-Side Request Forgery refers to a vulnerability whereby an attacker abuses server functionality in order to read, access or modify internal resources. The attack forces the application to send a request to an unexpected destination which will often bypass any security controls in place and allow the attacker to access unintended resources.

To mitigate this security risk the following preventative measures have been implemented:

• Not hosting the application on our own infrastructure or virtualised system gives us the advantage of being able to leverage the resources provided by Amazon and Vercel to protect our application.
• One of the advantages in using AWS serverless Lambda functions is that you afforded the protections offered by a large scale provider without being responsible for maintaining the security of the underlying operating system or services software.
• All user data is sanitised where required on the front-end, and the back-end.