Mitigation Strategy: Granular Permission Flags
Mitigation Strategy: Granular Permission Flags
* **Description:**
1. **Analyze Code:** Carefully examine your Deno code to determine the *precise* resources it needs (files, network, environment, subprocesses, etc.).
2. **Zero Permissions Start:** Run your Deno script initially with *no* `--allow-*` flags. This will cause failures, highlighting required permissions.
3. **Specific Flags:** Add only the *most specific* Deno permission flags. Use path restrictions and host/port limitations:
* `--allow-read=/specific/path/file.txt` (not `--allow-read`)
* `--allow-net=api.example.com:443` (not `--allow-net`)
* `--allow-env=API_KEY` (not `--allow-env`)
* `--allow-run=specific_command` (not `--allow-run`)
* `--allow-ffi=/path/to/specific/library.so` (and be *very* careful with FFI)
* `--allow-hrtime` (only if absolutely necessary)
4. **Development Prompting:** Use `--prompt` during development. Deno will ask for permission at runtime, helping you refine the flags.
5. **Continuous Testing:** Thoroughly test after each permission change.
6. **Document and Review:** Document all granted permissions and review them regularly.
* **Threats Mitigated:**
* **Arbitrary File System Access (High Severity):** Deno's permission model, when used correctly, prevents unauthorized file system access.
* **Uncontrolled Network Access (High Severity):** Deno's `--allow-net` flag, with specific host/port restrictions, controls network connections.
* **Environment Variable Exposure (Medium to High Severity):** Deno's `--allow-env` flag, with specific variable names, limits environment variable access.
* **Uncontrolled Subprocess Execution (High Severity):** Deno's `--allow-run` flag, with specific command restrictions, controls subprocess execution.
* **Foreign Function Interface Abuse (High Severity):** Deno's `--allow-ffi` flag, with specific library restrictions, limits FFI access.
* **Timing Attacks (Low to Medium Severity):** Deno's `--allow-hrtime` flag controls access to high-resolution timers.
* **Impact:**
* All listed threats: Risk significantly reduced (from High/Medium to Low/Negligible) when permissions are correctly configured.
* **Currently Implemented:**
* `main.ts`: Partially implemented (`--allow-net`, `--allow-read` with some restrictions).
* `data_processor.ts`: Fully implemented (specific file paths for read/write).
* **Missing Implementation:**
* `utils/helper.ts`: Uses `--allow-all` - needs complete refactoring.
* Testing scripts: Inconsistent permission usage.
Mitigation Strategy: Lock Files (deno.lock)
Mitigation Strategy: Lock Files (deno.lock)
* **Description:**
1. **Generate:** Run `deno cache --lock=deno.lock --reload` to create/update `deno.lock`. This file pins dependency versions and hashes.
2. **Version Control:** Commit `deno.lock` to your repository (e.g., Git).
3. **CI/CD Integration:** Ensure your CI/CD pipeline uses the lock file (often automatic, but may need `--lock=deno.lock`).
4. **Regular Updates:** Periodically run `deno cache --lock=deno.lock --reload` to update dependencies and review the changes.
* **Threats Mitigated:**
* **Dependency Confusion/Substitution (High Severity):** Deno's lock file, combined with its URL-based import system, prevents this.
* **Supply Chain Attacks (via Dependencies) (High Severity):** Deno's lock file reduces the risk of compromised dependencies by pinning versions.
* **Inconsistent Behavior (Medium Severity):** Ensures consistent dependency versions across environments.
* **Impact:**
* Dependency Confusion/Substitution: Risk significantly reduced (High to Low).
* Supply Chain Attacks: Risk reduced (High to Medium).
* Inconsistent Behavior: Risk significantly reduced (Medium to Low).
* **Currently Implemented:**
* `deno.lock` file exists and is committed.
* CI/CD uses the lock file.
* **Missing Implementation:** None.
Mitigation Strategy: Subresource Integrity (SRI) - Deno's Built-in Verification
Mitigation Strategy: Subresource Integrity (SRI) - Deno's Built-in Verification
* **Description:**
1. **Identify CDN Resources:** Find any external modules loaded from CDNs.
2. **Generate Hash:** Generate an SRI hash (SHA-256, SHA-384, or SHA-512) of the external resource's content.
3. **`integrity` Attribute:** Add the `integrity` attribute to the Deno import statement:
```typescript
import { x } from "https://cdn.example.com/lib.js?integrity=sha384-...";
```
4. **Deno Verification:** Deno *automatically* verifies the integrity hash against the downloaded resource.
* **Threats Mitigated:**
* **Man-in-the-Middle (MITM) Attacks (High Severity):** Deno's SRI verification prevents execution of modified resources.
* **Compromised CDN (High Severity):** Deno's SRI check fails if the CDN serves a different file.
* **Tampering (High Severity):** Deno ensures the downloaded code matches the expected hash.
* **Impact:**
* All listed threats: Risk significantly reduced (High to Low/Negligible).
* **Currently Implemented:**
* Used for main application dependencies from `cdn.skypack.dev`.
* **Missing Implementation:**
* `utils/charting.ts`: Loads a library from another CDN without SRI.
Mitigation Strategy: Import Maps (Deno's Module Resolution Control)
Mitigation Strategy: Import Maps (Deno's Module Resolution Control)
* **Description:**
1. **Create `deno.json` or `import_map.json`:** Create one of these files in your project root.
2. **Define Mappings:** Map module specifiers to specific URLs or local paths:
```json
{
"imports": {
"std/": "https://deno.land/[email protected]/",
"lodash": "https://cdn.skypack.dev/[email protected]"
}
}
```
3. **Use Aliases:** Use aliases in your import statements for clarity and control.
4. **Deno's Resolution:** Deno uses the import map to resolve module locations.
5. **Regular Updates:** Update the import map as dependencies change.
* **Threats Mitigated:**
* **Dependency Confusion/Substitution (High Severity):** Deno's import map, by explicitly defining module sources, prevents this.
* **Supply Chain Attacks (via Dependencies) (High Severity):** Provides control over module origins.
* **Typosquatting (Medium Severity):** Reduces the risk of importing similarly named malicious modules.
* **Impact:**
* Dependency Confusion/Substitution: Risk significantly reduced (High to Low).
* Supply Chain Attacks: Risk reduced (High to Medium).
* Typosquatting: Risk significantly reduced (Medium to Low).
* **Currently Implemented:**
* `import_map.json` exists and maps `std/` imports.
* **Missing Implementation:**
* Not used for all third-party dependencies; needs to be expanded.