Defend your home: Real-world Threat Modeling – Part 2 of 3

Introduction

In the first blog post about threat modeling we focused our efforts on the theoretical basis, addressing the development and different methodologies. Now, in this second part of the article on threat modeling, we will demonstrate in a practical way how to model threats in an application, as well as the security requirements to prevent these threats from becoming vulnerabilities.

To apply the modeling in practice, we will use as an example a Capture The Flag (CTF) application hosted on the Hacking Club. The "Stonks" machine represents a scenario of an application that creates dashboards of personal investment portfolios, performing queries on an external API. This allows us to perform a complete threat modeling external to a real scenario, as well as the subsequent exercise that consists of performing security requirements tests. In this case, the application is already developed, “in production”, so we will show how to avoid the vulnerabilities it presents if it goes through an adequate threat modeling process. We will create the modeling based on 4 questions, according to the Threat Modeling Manifesto:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

What are we working on?

Understanding the application

Abaixo são listadas as informações que temos sobre a aplicação:

• Stacks:
  • VueJS on the front-end
  • PHP Laravel 11.0 on the backend
• External API used:
  • Yahoo Finance

To understand the whole scenario more clearly, we need the design of the application architecture with the technologies used. This can be provided by the architecture team or we can do it together with the business team when there is no software blueprint yet. Figure 1 shows the high-level architectural design of the application that will be evaluated:

Figure 1 - High-level application architecture design

As shown in the architectural drawing, we can identify the entire application flow, from user interaction to requests made to an external system. The user accesses the application through a website, where they can register and authenticate. The application is hosted on AWS, uses PHP as its main language in the backend, and its main features are the login screen, registration screen, and investment dashboard. User data is stored in a MySQL database, and the application communicates with a microservices API, which in turn obtains information about investment assets through Yahoo Finance. With this entire structure in hand, we begin mapping the assets, starting our threat modeling.

What could go wrong? 

Identifying Assets

To bring threat modeling to life, we begin by identifying and scoring essential elements in the diagrams, starting with the assets.

In threat modeling, as seen in the first part of the article, assets represent the important elements that need to be protected against attacks. They include everything from sensitive information, such as customer personal data, to IT systems, such as physical infrastructure. Each asset has a specific value and, if compromised, can cause serious damage to the company, such as financial loss or data leaks. Identifying assets is one of the first steps in assessing threats and vulnerabilities, so we have an idea of ​​what we are going to start evaluating, ensuring that security measures are focused on what is most important to the business.

In order to map assets, we can imagine a house that contains valuable objects, such as electronics, jewelry and other items of great importance. In this context, assets are represented by these valuable items, which need to be protected to prevent them from being stolen or compromised.

Having a clear vision of asset mapping, we began to list and position our infrastructure assets as described below:

Figure 2 - Mapping the assets that run through the data flow in the application

Each green box represents an asset within the architecture, which are highlighted in Figure 3.

Figure 3 - Assets mapped in the application

The assets highlighted in our modeling are classified as high priority. Therefore, they must receive attention in the implementation of security controls, ensuring protection against potential threats.

To facilitate identification and tracking, each asset will be designated by an acronym in the format A01, A02, and so on.

• A01 - Authentication credentials
• A02 - User registration data
• A03 - Database credentials
• A04 - Investment and financial information
• A05 - Stock exchange transaction records

Modeling the Threats

We have mapped all the assets in our infrastructure. Now, let’s start identifying threats using the analogy of a house. How could an attacker access this house to steal valuable items? For example, he could use a copy of the key to open the door. If the door is unlocked, he could enter the house or even jump out the window. This logic helps us visualize how vulnerability threats allow unauthorized access to assets and the environment and cause various problems.

Based on this analogy, we will now map the threats in our infrastructure, analyzing each previously identified asset. In Figure 4 we can see the threats mapped in the application.

Figure 4 - Threats mapped in the application

Our entire structure has been mapped, associating potential threats to each previously identified asset. To facilitate identification, each threat will be designated with the acronym "T", and will be numbered sequentially as T01, T02, and so on.

The threats were mapped as follows:

• T01 - SQL injection: an attacker could tamper with database queries to retrieve sensitive data from other users.
• T02 - Brute force attack: an attacker could attempt to access an account or server through trial and error, using combinations of passwords and usernames until finding the correct one.
• T03 - Authentication bypass: an attacker could access functionality or data without authentication by manipulating parameters, exploiting unprotected endpoints, or reusing invalid tokens.
• T04 - Broken object level authorization (BOLA): an attacker could access, modify, or delete objects belonging to other users by manipulating resource identifiers (such as IDs) in requests or exploiting flaws in permissions checking.
• T05 - User enumeration: an attacker could identify valid or invalid users based on application responses, such as different error messages, varying response times, or other behaviors that reveal the existence of accounts.
• T06 - Cross-site Scripting (XSS): an attacker could inject malicious scripts into web pages that are viewed by other users, allowing them to steal cookies, redirect users, perform actions on behalf of the victim, or exfiltrate sensitive data.
• T07 - Session hijacking: an attacker could steal or hijack another user's active session, using techniques such as intercepting session cookies, exploiting flaws in authentication tokens, or manipulating session parameters to impersonate another user.
• T08 - Phishing: an attacker could trick users into providing sensitive information, such as credentials, through fraudulent messages, emails, or spoofed websites that imitate trusted sources.
• T09 - Server-side Request Forgery (SSRF): an attacker could manipulate the application to make HTTP requests to internal or external resources that the application should not access, exploiting flaws in input validation and potentially, for example, obtaining confidential information or carrying out attacks on internal systems.
• T10 - Broken function level authorization (BFLA): an attacker could access or execute functions restricted to users with higher privileges by manipulating parameters or taking advantage of flaws in permission checking, allowing them to perform actions that should be restricted to administrators or users with specific permissions.

Once we have completed mapping the threats in our structure, we can see that our assets will be vulnerable to several problems if we do not implement adequate protection mechanisms to mitigate them. Therefore, the next step is to describe the controls and security requirements to prevent the threats from materializing.

Classifying the threats

Once the threats have been defined, we can classify them according to the STRIDE categories, with the aim of understanding the type of threat and proposing appropriate controls later. Table 1 presents the classification of threats.

Table 1 - Classification of threats according to STRIDE category

Assigning severities

After mapping all the threats in our framework and classifying them, we can assign severity scores according to CVSS.

Table 2 - Threat classification according to STRIDE framework categories

What are we going to do about it?

Defining security requirements and controls

Control requirements represent the security mechanisms that must be implemented on our assets to protect them from the threats identified above.

Using the analogy of a house, to protect our most valuable assets, we can adopt various security methods, such as installing cameras with alarms to alert authorities in case of intrusion, locking doors and windows, and implementing other protective measures against unauthorized access.

Just as it is essential to think like a good attacker to identify potential threats, it is also important to act like a skilled defender, designing and applying control points that address all threats present in the structure. And to define effective controls against threats, it is necessary to know how the attacks work, that is, through the offensive mindset. In addition, to define the controls, we can use frameworks such as OWASP ASVS, CIS Controls and NIST SCF as reference. Figure 5 demonstrates the controls proposed in our threat modeling.

Figure 5 - Controls positioned in the application drawing

Table 3 contains the recommended controls based on the anticipated threat scenarios.

Table 3 - Recommended controls for the current threat scenario

C01 - Query Parameterization:

• Ensure that special characters in input data are properly escaped to prevent malicious code injections;
• Escape special characters in queries and commands to protect against injection attacks in databases and other systems.
• Ensure the authenticity and integrity of communications, preventing unauthorized manipulation during the exchange of information.

C02 - Rate Limit:

• Implement rate limits to restrict the number of requests that can be made in a given period of time;
• Monitor and log requests to identify suspicious or malicious activity;
• Implement differentiated limits based on different types of requests or users.

C03 - Robust access control: 

• Define clear roles and permissions for users based on their responsibilities and roles in the organization, ensuring that only authorized users have access to critical resources.
• Require multiple authentication factors, such as passwords, tokens, or biometrics, to improve security and ensure that access is granted only to legitimate users.
• Ensure that user sessions are properly managed, with automatic expiration after periods of inactivity, and providing the ability to revoke active sessions if unauthorized access is suspected.

C04 - Generic error message:

• Ensure that errors do not reveal information about the system configuration, such as environment details, API keys, or database credentials.
• Use a standard error message that clearly informs the user that something went wrong, without providing information that could be exploited. For example, "Failed to process your request. Please try again later."
• When providing APIs, error responses should be standardized, with appropriate HTTP codes (e.g., 400 for request error, 500 for internal server error) and without technical details that could be used maliciously.

C05 - Multi-factor authentication:

• Ensure that all systems and accounts that handle sensitive data or provide access to critical resources use multifactor authentication. This includes user accounts, administrator accounts, and API access.
• In addition to initial authentication, require MFA for high-risk operations, such as financial transactions, changing security settings, or modifying critical data.
• Implement periodic MFA checks for long-running sessions, or for suspicious activity, such as logging in from a new device or different geographic location.

C06 - Session Invalidation:

• Implement automatic expiration of user sessions after a defined period of inactivity. This helps minimize the risk of unauthorized access if a user forgets to log out of their account or leaves their device unprotected.
• Ensure that upon logout, all session tokens and session identifiers are properly invalidated on the server so that the session cannot be reused or restored.
• Whenever a user changes their credentials (such as password or email), all active sessions associated with the user should be invalidated, forcing a re-login to ensure security.

C07 - URL validation in the backend:

• Ensure that the provided URLs are validated against a list of trusted domains before being processed by the backend. URLs outside of this list should be rejected.
• Restrict the backend from accessing local or private addresses, such as localhost or 127.0.0.1, to prevent exploitation of internal resources through malicious requests.
• Ensure that the backend logs all requests for external URLs, enabling audits and identifying potential abuse attempts.

C08 - Data encryption at rest:

• Use encryption keys stored securely, separate from the system accessing the data, to prevent accidental exposure or theft of the keys.
• Implement encryption on disks and storage devices (Full Disk Encryption) to protect data in the event of theft or physical loss of hardware.
• Adopt the practice of periodic rotation of encryption keys, minimizing the impact if a key is compromised.

When presenting threat modeling as a whole to the development team, it is important that they understand the controls and where they should be implemented. To monitor this process, it is possible to establish a checklist with the three requirements for each control, and, with this, allow the developer to confirm the controls already developed. Table 4 presents a simple checklist, in which the “Status” column could be used to monitor the implementation of the controls.

Table 4 - Control checklist

Wrapping up

At the end of the process, we have a complete threat model with established controls. To facilitate the process of implementing them, we created a checklist with what the developer must implement.

However, after all this process, we are still not sure whether threat modeling and controls are sufficient to protect the application, and with that, the last question from the manifesto we brought up in the introduction comes to mind: Did we do a good job? We will answer it in the third and final part of this article, through requirements testing in which we will promptly attack the application, seeking to validate these controls and even find additional points that may have been left out of the threat modeling.