5.2.1 - Example
We have already established a strong foundation with our solid test cases included in the Requirements Traceability Matrix (RTM), which provides an excellent starting point for penetration testing. However, the process doesn’t end there; it now extends to the dynamic and often unpredictable art of ad hoc testing—essentially the practice of ‘experimenting to discover.’ AKA the power of F*** around and find out.
This phase builds upon the knowledge accumulated from previous stages, encouraging to navigate through the application with meticulous attention. It involves an in-depth review where testers read through the code more thoroughly and scrutinize the application’s behaviour with acute vigilance, much like a hawk. The objective is to spot any irregularities or ‘off’ elements that might suggest underlying vulnerabilities. Here, intuition and creativity play crucial roles in uncovering new and interesting security weaknesses.
Gaining proficiency in this phase comes with experience, which is primarily acquired through practical engagement and continuous learning.
For those seeking a structured approach or needing inspiration to understand the full breadth of the attack surface, I recommend utilizing the following resource as a checklist. This tool helps in checking and cross-referencing the controls associated with the technologies and functions in your target environment, aiding in the derivation of novel and pertinent test cases:
OWASP Web Application Penetration Checklist
Having this checklist at your disposal can provide a solid groundwork and starting point for creative and effective penetration testing.
| Feature ID | Description | potential Vulnerability | Test Method | References |
|---|---|---|---|---|
| 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 jsonwebtoken <=8.5.1 CVE-2022-23540 https://github.com/advisories/GHSA-qwph-4952-7xr6 Also, verify by decoding the JWT that no sensitive information goes in there. |
SCA scanning output. |
| 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 |
Screenshot-1 |
| F003 | SpikyFactor.js | RCE | SonarQube detected a potential RCE in the calculate function of the challenge/helpers/SpikyFactor.js |
Screenshot-2 |
| F004 | index.js | CSRF | No CSRF middleware detected verify if we can perform CSRF somewhere in the app | Semgrep output |
In the context of the HTB machine that we are testing now we just want to focus on the most high impact findings so that we ultimately can retrieve the flag. In a real world application we also want to verify the different set of controls that we gathered in previous chapters with the ASVS.
| 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. | ✓✓✓ |
To fit the final puzzle pieces together on how this application was exploited we included the write-up of the machine. As you can see all the flaws to successfully collect the flag of the application are present in the RTM. PDF here
The next chapters are to give extra inspiration of different flows and logic flaws to test for a more thorough investigation to be applied in future assessments.