2.3.1 - Example
Understand the Application’s Business Logic
First we check all the different documentations of the components that are being used and understand if there are any significant security concerns using/implementing these stacks.
Reading the documentation for the mysqljs we already find some interesting security concerns to take into account during our full review:
https://github.com/mysqljs/mysql https://github.com/mysqljs/mysql/blob/master/Readme.md#escaping-query-values
Let’s again add this finding already to the RTM to investigate later
| Feature ID | Description | potential Vulnerability | Test Method |
|---|---|---|---|
| F001 | User Authentication | JWT is prone to signature bypasses | SCA should point out CVE. There is also other methods of attack that need to be tested described here: https://portswigger.net/web-security/jwt |
| F002 | User login | SQLI | A potential POC can be build following this resource. https://flattsecurity.medium.com/finding-an-unseen-sql-injection-by-bypassing-escape-functions-in-mysqljs-mysql-90b27f6542b4 |
Conduct Brainstorming Sessions
It is challenging to provide a concrete life example for this aspect of our work, as the process is highly dynamic and organic, particularly when performing threatmodeling using Escalation of Privileges (EoP) cardgame. Nevertheless, we can leverage the information we have to select a set of Application Security Verification Standard (ASVS) controls that aid in formulating specific test cases to apply to the application. While EoP is an invaluable resource, it is not the sole tool at our disposal, and proficiency in its use will enhance over time with experience.
In this part of the process by actively navigating through the application, reviewing the source code, and engaging with developers we gain a good understanding in what ASVS topics we should select test controls. This comprehensive approach ensures that we achieve the best possible results within the most relevant scope, enabling a thorough and effective penetration testing process.
Given what we already know about the application let’s gather some ASVS controls that could facilitate us during testing. What do we know about the app so far?
- Techstecks
- Mysql
- NodeJS
- JWT for authentication/authorization
- Session based session management
- security flags like
httpOnly,sameSiteetc become important - JWT has known implementation flaws
- security flags like
- Session based session management
- Functionality
- Login page
- Authentication authorization requirements
- Registration page
- Password storage/handling requirements
- Functions to interact with tamagotchi
- Login page
Again, as the process is highly dynamic and organic, we might come up with different controls each time we do this exercise, even for the same codebase. However, performing these tasks does provide some interesting pathways that we could test over the app, which seem highly important to implement to prevent critical breaches.
| Req ID | Req Description | Levels |
|---|---|---|
| V1.2.2 | Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed. (C3) | ✓✓ |
| V1.2.3 | Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches. | ✓✓ |
| V1.2.4 | Verify that all authentication pathways and identity management APIs implement consistent authentication security control strength, such that there are no weaker alternatives per the risk of the application. | ✓✓ |
| V1.4.4 | Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths. (C7) | ✓✓ |
| V1.4.5 | Verify that attribute or feature-based access control is used whereby the code checks the user’s authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. (C7) | ✓✓ |
| V1.11.1 | Verify the definition and documentation of all application components in terms of the business or security functions they provide. | ✓✓ |
| V2.1.1 | Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). (C6) | ✓✓✓ |
| V2.1.7 | Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system’s password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. (C6) | ✓✓✓ |
| V2.4.1 | Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one-way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash. (C6) | ✓✓ |
| V3.1.1 | Verify the application never reveals session tokens in URL parameters. | ✓✓✓ |
| V3.2.1 | Verify the application generates a new session token on user authentication. (C6) | ✓✓✓ |
| V3.4.3 | Verify that cookie-based session tokens utilize the ‘SameSite’ attribute to limit exposure to cross-site request forgery attacks. (C6) | ✓✓✓ |
| V4.2.1 | Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else’s record, viewing everyone’s records, or deleting all records. | ✓✓✓ |
| V4.2.2 | Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality. | ✓✓✓ |
| V5.1.4 | Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). (C5) | ✓✓✓ |
| V11.1.1 | Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps. | ✓✓✓ |
| V11.1.2 | Verify that the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly. | ✓✓✓ |
| V11.1.3 | Verify the application has appropriate limits for specific business actions or transactions which are correctly enforced on a per user basis. | ✓✓✓ |
Prototype and Test Attack Scenarios
Based on the assumptions we have made about the vulnerabilities we have found we include sources or ideas on how to build an attack. From what you have seen in the examples already shown, this is a bit of dynamic process where we gather these “Test Methods” organically whilst putting stuff on the RTM.