|
| 1 | +## Threat Model for resolve (module path resolution library) |
| 2 | + |
| 3 | +### 1. Library Overview |
| 4 | + |
| 5 | +- **Library Name:** resolve |
| 6 | +- **Brief Description:** Implements Node.js `require.resolve()` algorithm for synchronous and asynchronous file path resolution. Used to locate modules and files in Node.js projects. |
| 7 | +- **Key Public APIs/Functions:** `resolve.sync()` / `resolve/sync`, `resolve()` / `resolve/async` |
| 8 | + |
| 9 | +### 2. Define Scope |
| 10 | + |
| 11 | +This threat model focuses on the core path resolution algorithm, including filesystem interaction, option handling, and cache management. |
| 12 | + |
| 13 | +### 3. Conceptual System Diagram |
| 14 | + |
| 15 | +``` |
| 16 | +Caller Application → resolve(id, options) → Resolution Algorithm → File System |
| 17 | + │ |
| 18 | + └→ Options Handling |
| 19 | + └→ Cache System |
| 20 | +``` |
| 21 | + |
| 22 | +**Trust Boundaries:** |
| 23 | +- **Input module IDs:** May come from untrusted sources (user input, configuration) |
| 24 | +- **Filesystem access:** The library interacts with the filesystem to resolve paths |
| 25 | +- **Options:** Provided by the caller |
| 26 | +- **Cache:** Used to improve performance, but could be a vector for tampering or information disclosure if not handled securely |
| 27 | + |
| 28 | +### 4. Identify Assets |
| 29 | + |
| 30 | +- **Integrity of resolution output:** Ensure correct and safe file path matching. |
| 31 | +- **Confidentiality of configuration:** Prevent sensitive path information from being leaked. |
| 32 | +- **Availability/performance for host application:** Prevent crashes or resource exhaustion. |
| 33 | +- **Security of host application:** Prevent path traversal or unintended filesystem access. |
| 34 | +- **Reputation of library:** Maintain trust by avoiding supply chain attacks and vulnerabilities[1][3][4]. |
| 35 | + |
| 36 | +### 5. Identify Threats |
| 37 | + |
| 38 | +| Component / API / Interaction | S | T | R | I | D | E | |
| 39 | +|-----------------------------------------------------|----|----|----|----|----|----| |
| 40 | +| Public API Call (`resolve/async`, `resolve/sync`) | ✓ | ✓ | – | ✓ | – | – | |
| 41 | +| Filesystem Access | – | ✓ | – | ✓ | ✓ | – | |
| 42 | +| Options Handling | ✓ | ✓ | – | ✓ | – | – | |
| 43 | +| Cache System | – | ✓ | – | ✓ | – | – | |
| 44 | + |
| 45 | +**Key Threats:** |
| 46 | +- **Spoofing:** Malicious module IDs mimicking legitimate packages, or spoofing configuration options[1]. |
| 47 | +- **Tampering:** Caller-provided paths altering resolution order, or cache tampering leading to incorrect results[1][4]. |
| 48 | +- **Information Disclosure:** Error messages revealing filesystem structure or sensitive paths[1]. |
| 49 | +- **Denial of Service:** Recursive or excessive resolution exhausting filesystem handles or causing application crashes[1]. |
| 50 | +- **Path Traversal:** Malicious input allowing access to files outside the intended directory[4]. |
| 51 | + |
| 52 | +### 6. Mitigation/Countermeasures |
| 53 | + |
| 54 | +| Threat Identified | Proposed Mitigation | |
| 55 | +|--------------------------------------------|---------------------| |
| 56 | +| Spoofing (malicious module IDs/config) | Sanitize input IDs; validate against known patterns; restrict `basedir` to app-controlled paths[1][4]. | |
| 57 | +| Tampering (path traversal, cache) | Validate input IDs for directory escapes; secure cache reads/writes; restrict cache to trusted sources[1][4]. | |
| 58 | +| Information Disclosure (error messages) | Generic "not found" errors without internal paths; avoid exposing sensitive configuration in errors[1]. | |
| 59 | +| Denial of Service (resource exhaustion) | Limit recursive resolution depth; implement timeout; monitor for excessive filesystem operations[1]. | |
| 60 | + |
| 61 | +### 7. Risk Ranking |
| 62 | + |
| 63 | +- **High:** Path traversal via malicious IDs (if not properly mitigated) |
| 64 | +- **Medium:** Cache tampering or spoofing (if cache is not secured) |
| 65 | +- **Low:** Information disclosure in errors (if error handling is generic) |
| 66 | + |
| 67 | +### 8. Next Steps & Review |
| 68 | + |
| 69 | +1. **Implement input sanitization for module IDs and configuration.** |
| 70 | +2. **Add resolution depth limiting and timeout.** |
| 71 | +3. **Audit cache handling for race conditions and tampering.** |
| 72 | +4. **Regularly review dependencies for vulnerabilities.** |
| 73 | +5. **Keep documentation and threat model up to date.** |
| 74 | +6. **Monitor for new threats as the ecosystem and library evolve[1][3].** |
0 commit comments