You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by as...@apache.org on 2026/05/05 20:53:11 UTC

(tooling-agents) branch main updated: ASVS audit: 13.4.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

This is an automated email from the ASF dual-hosted git repository.

asf-tooling pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tooling-agents.git


The following commit(s) were added to refs/heads/main by this push:
     new 43ab6ab  ASVS audit: 13.4.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
43ab6ab is described below

commit 43ab6ab0b9e729c20c585e4a62cf2ab0c62d1050
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:53:04 2026 +0200

    ASVS audit: 13.4.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/13.4.1.md | 138 ++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/13.4.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/13.4.1.md
new file mode 100644
index 0000000..fe81bc7
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/13.4.1.md
@@ -0,0 +1,138 @@
+# Security Audit Report: ASVS 13.4.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 13.4.1 |
+| **Files Analyzed** | 7 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application is deployed either without any source control metadata, including the .git or .svn folders, or in a way that these folders are inaccessible both externally and to the application itself.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-13.4.1: No Source Control Metadata Deployed
+
+### Findings for 13.4.1
+
+### [MEDIUM]
+
+**Finding ID**: ASVS-1341-MED-001
+
+**File**: `v3/server/pages.py` (lines 577-578)
+
+**Vulnerable Code**:
+```python
+@APP.get('/static/<path:filename>')
+async def serve_static(filename):
+    return await quart.send_from_directory(STATICDIR, filename)
+```
+
+**Data Flow**: HTTP request with `filename` parameter → `send_from_directory(STATICDIR, filename)` → file served from `STATICDIR`.
+
+**Impact**: The `<path:filename>` converter accepts paths with subdirectories (e.g., `.git/config`, `.svn/entries`). If a `.git` or `.svn` folder exists within `STATICDIR` (which could occur from development/deployment practices), it would be served to clients. While `send_from_directory` should prevent path traversal above the root, it will serve any file within the directory tree including source control metadata.
+
+**Proof of Concept**:
+```
+GET /static/.git/config HTTP/1.1
+GET /static/.git/HEAD HTTP/1.1
+GET /static/.svn/entries HTTP/1.1
+```
+
+**Remediation**:
+```python
+import re
+
+BLOCKED_PATHS = re.compile(r'(^|/)\.(git|svn|hg|bzr)(/|$)', re.IGNORECASE)
+
+@APP.get('/static/<path:filename>')
+async def serve_static(filename):
+    if BLOCKED_PATHS.search(filename):
+        quart.abort(404)
+    return await quart.send_from_directory(STATICDIR, filename)
+```
+
+### [LOW]
+
+**Finding ID**: ASVS-1341-LOW-001
+
+**File**: `v3/server/pages.py` (lines 560-574) 
+
+**Vulnerable Code**:
+```python
+@APP.get('/docs/<iid>/<docname>')
+@asfquart.auth.require
+async def serve_doc(iid, docname):
+    ...
+    return await quart.send_from_directory(DOCSDIR / iid, docname)
+```
+
+**Impact**: Similar to the static endpoint, if `.git` or `.svn` metadata exists in `DOCSDIR/iid/` directories, it could be served. The risk is lower here because authentication is required and the path is more constrained (single filename, not a path), but should still be addressed.
+
+**Remediation**: Add explicit blocking of source control metadata filenames:
+```python
+if docname.startswith('.git') or docname.startswith('.svn'):
+    quart.abort(404)
+```
+
+### Security Controls Inventory for 13.4.1
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Explicit SCM directory blocking | N/A | **MISSING** - no blocking configured |
+| Deployment configuration | N/A | **NOT IN SCOPE** - no deployment config provided |
+| `send_from_directory` path safety | `pages.py:578,574` | EXISTS - prevents traversal above root but not SCM access within tree |
+
+### Positive Patterns for 13.4.1
+
+- Application uses scoped directory serving (`send_from_directory`) rather than exposing filesystem root
+- File serving endpoints are limited to specific known directories (`STATICDIR`, `DOCSDIR`)
+- The application doesn't serve from the project root directory directly
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Key Material Exposure Pattern**: The application handles all cryptographic operations in-process with no isolation boundary. The `opened_key` (master election key) flows through multiple code paths: `election.open()` → SQLite storage → `add_vote()` → `tally_issue()` → `has_voted_upon()`. Any single compromise point in this chain exposes all election vote data.
+
+2. **Lifecycle Gap**: The election lifecycle (editable → open → closed) provides a natural framework for key management, but key material persists in the `closed` state indefinitely. There's no "archived" or "destroyed" state where key material would be removed.
+
+3. **Defense-in-Depth Gaps**: Multiple requirements share a common theme of missing explicit hardening. The framework provides reasonable defaults (no TRACE, no directory listing, method restrictions) but there's no explicit defense-in-depth configuration. This creates risk if framework behavior changes or if deployment differs from assumptions.
+
+4. **Development Artifacts in Production Code**: Multiple indicators suggest the code is not fully production-hardened: placeholder CSRF token, active `print()` statements, `### check authz` comments indicating incomplete authorization, and commented-out debug statements for sensitive values.
+
+5. **Single Database as Secret Store**: SQLite serves as both the application database and the secrets store. There's no separation between operational data and key material, making it impossible to apply different access controls or audit requirements to secrets vs. general data.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical Path)
+1. **Remove debug `print()` statements** from `do_add_issue_endpoint` and `do_edit_issue_endpoint` - these actively leak form data to stdout in production
+2. **Add explicit source control metadata blocking** to the `/static/` route to prevent serving `.git` contents if accidentally deployed
+3. **Document deployment requirements** explicitly stating that TRACE must be disabled at reverse proxy level and directory listing must be disabled
+
+### Short-term (1-3 months)
+4. **Implement key lifecycle management** - add `key_created_at` tracking to the schema, implement secret cleanup after election finalization (e.g., zeroing `opened_key` after results are exported/verified)
+5. **Add explicit TRACE blocking middleware** and source control path filtering as defense-in-depth measures
+6. **Remove all commented-out debug code** that could expose sensitive key material if uncommented
+7. **Implement environment-based configuration** to ensure debug-level features are disabled in production builds
+
+### Long-term (3-12 months)
+8. **Integrate with a key management service** (HashiCorp Vault, AWS KMS, or similar) to perform cryptographic operations in an isolated security boundary - this is the most significant gap for a Level 3 ASVS target
+9. **Implement secret rotation** - design a mechanism to rotate election keys for long-running elections, or implement a maximum election duration policy
+10. **Separate secret storage** from operational database - consider storing key material in a dedicated secrets backend with its own access controls and audit trail
+        
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@tooling.apache.org
For additional commands, e-mail: commits-help@tooling.apache.org