(tooling-agents) branch main updated: ASVS audit: 13.4.6.md (redacted)

[as...@apache.org]

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 64ab8fe  ASVS audit: 13.4.6.md (redacted)
64ab8fe is described below

commit 64ab8fe56750104793955b62073414a1aa5828eb
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:03:46 2026 +0200

    ASVS audit: 13.4.6.md (redacted)
---
 ASVS/reports/steve/v3/d0aa7e9/all/13.4.6.md | 152 ++++++++++++++++++++++++++++
 1 file changed, 152 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/13.4.6.md b/ASVS/reports/steve/v3/d0aa7e9/all/13.4.6.md
new file mode 100644
index 0000000..a2c43b2
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/13.4.6.md
@@ -0,0 +1,152 @@
+# Security Audit Report: ASVS 13.4.6
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 13.4.6 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application does not expose detailed version information of backend components.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-13.4.6: Unintended Information Leakage - Version Information
+
+### Findings for 13.4.6
+
+#### [MEDIUM]
+**Finding ID**: ASVS-1346-MED-001
+
+**File**: `v3/server/pages.py` (application configuration)
+
+**Issue**: No configuration is visible for suppressing server version headers. Quart (the ASGI framework in use) runs on Hypercorn by default, which sends `Server: hypercorn-h11` headers revealing the server technology and HTTP library version. No middleware or response processing is configured to strip or override these headers.
+
+**Data Flow**: Any HTTP response → Quart/Hypercorn default headers → Client receives `Server` header with version information
+
+**Proof of Concept**:
+```
+$ curl -I https://target/about
+HTTP/1.1 200 OK
+Server: hypercorn-h11
+...
+```
+
+**Impact**: Attackers can identify the exact web server technology and version, enabling targeted exploit research. This is typically chained with other vulnerabilities.
+
+**Remediation**:
+```python
+@APP.after_request
+async def remove_version_headers(response):
+    response.headers.pop('Server', None)
+    response.headers.pop('X-Powered-By', None)
+    return response
+```
+
+Or in Hypercorn configuration:
+```toml
+[hypercorn]
+include_server_header = false
+```
+
+---
+
+#### [LOW]
+**Finding ID**: ASVS-1346-LOW-001
+
+**File**: `v3/steve/crypto.py`, line 65 (comment) and `v3/docs/schema.md`
+
+**Relevant Code** (crypto.py):
+```python
+### still using Fernet now, but will switch soon. Leaving comments.
+keymaker = hkdf.HKDF(
+    algorithm=hashes.SHA256(),
+    length=32,  # 32-byte key for XChaCha20-Poly1305
+    salt=salt,
+    info=b'xchacha20_key',
+)
+```
+
+**Relevant Documentation** (schema.md):
+```markdown
+- `ciphertext` in `vote` uses Fernet encryption (to be replaced with XChaCha20-Poly1305).
+```
+
+**Issue**: While these are source-level comments and documentation (not directly exposed to users), the HKDF `info` parameter `b'xchacha20_key'` embeds future technology choices into the cryptographic derivation itself. If error messages or debug output ever expose this, it would reveal the cryptographic stack.
+
+**Impact**: Low direct impact. Information about cryptographic libraries and algorithms could be exposed through error messages or stack traces if unhandled exceptions occur.
+
+**Remediation**: Ensure error handlers never expose stack traces in production. Use generic `info` parameter values.
+
+### Security Controls Inventory for 13.4.6
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Server header suppression | N/A | **NOT IMPLEMENTED** |
+| Error handler (hiding stack traces) | Not visible in code | **UNKNOWN** |
+| Custom error pages | `pages.py:647` (`raise_404`) | Partial (only 404) |
+| Library version suppression in responses | N/A | **NOT IMPLEMENTED** |
+
+### Positive Patterns for 13.4.6
+
+1. **No explicit version strings in templates**: The templates and served content don't include version numbers of backend components.
+2. **Database version not exposed**: SQLite version is never returned to clients.
+3. **Crypto library versions not exposed in API responses**: The cryptographic implementation details stay server-side.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Type B Gap Pattern (Control exists but not called)**: The most pervasive security issue across this codebase is the `### check authz` pattern. Authorization logic is acknowledged as needed (via comments) throughout `pages.py` but is never implemented. This creates false confidence — the code appears to have considered authorization, but any authenticated committer can manage any election, open/close any election, or manipulate any issue regardless of ownership.
+
+2. **Documentation vs. Implementation Asymmetry**: The `schema.md` documentation describes a well-thought-out security architecture (non-predictable IDs, encryption, anti-tamper), but the running application has significant gaps (CSRF placeholder, missing authz, unvalidated file serving).
+
+3. **Positive Crypto Architecture**: The cryptographic design (Argon2 for key derivation, per-voter salts, Fernet encryption, vote shuffling) is well-implemented in `crypto.py` and `election.py`. The separation of concerns (crypto operations isolated in one module) supports auditability.
+
+4. **Data Leakage Prevention in Queries**: The `queries.yaml` demonstrates conscious effort to prevent sensitive data leakage — public-facing queries explicitly exclude `salt` and `opened_key` columns, with comments documenting this decision. The `_all_metadata()` method is correctly marked as internal-only.
+
+5. **Incomplete Defense-in-Depth**: Authentication is applied (decorators on all sensitive endpoints), but authorization (who can do what to which resource) and input validation (file extensions, path components) represent the missing layers.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical/High Priority)
+
+1. **Convert state-changing GET endpoints to POST**: Change `/do-open/<eid>` and `/do-close/<eid>` from GET to POST, requiring form submission with CSRF tokens. This addresses both ASVS 14.2.1 (operations in URLs) and CSRF vulnerability.
+
+2. **Implement file extension whitelist**: Add allowed extension sets for both `/static/` and `/docs/` endpoints. This directly addresses ASVS 13.4.7 and prevents accidental file disclosure.
+
+3. **Validate `docname` parameter**: Implement the already-planned validation noted by the `### verify the propriety of DOCNAME` comment. Block path traversal characters and restrict to allowed extensions.
+
+### Short-term (Within Sprint)
+
+4. **Suppress server version headers**: Add an `@APP.after_request` handler to remove `Server` and `X-Powered-By` headers, or configure Hypercorn to disable server header inclusion (ASVS 13.4.6).
+
+5. **Implement authorization checks**: Replace all `### check authz` comments with actual ownership/permission verification. At minimum, verify `election.owner_pid == result.uid` for management operations.
+
+6. **Create data classification document**: Formally document all sensitive data types, their protection levels, and required controls (ASVS 14.1.1, 14.1.2).
+
+### Long-term (Architecture)
+
+7. **Implement CSRF protection**: Replace `basic.csrf_token = 'placeholder'` with cryptographically-generated per-session tokens validated on all state-changing endpoints.
+
+8. **Create comprehensive data protection policy**: Document encryption requirements, retention periods, logging policies, key management lifecycle, and privacy controls for each data sensitivity level.
+
+9. **Add security headers middleware**: Implement `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, `X-Frame-Options`, and `Strict-Transport-Security` headers to complement the data protection controls.
+        
\ 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