(tooling-agents) branch main updated: ASVS audit: 15.2.5.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 8eb54e1  ASVS audit: 15.2.5.md (redacted)
8eb54e1 is described below

commit 8eb54e1f7dbf7d761cbbb2a209f499fe77018915
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:04:28 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/15.2.5.md b/ASVS/reports/steve/v3/d0aa7e9/all/15.2.5.md
new file mode 100644
index 0000000..e0a85e9
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/15.2.5.md
@@ -0,0 +1,180 @@
+# Security Audit Report: ASVS 15.2.5
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 15.2.5 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application implements additional protections around parts of the application which are documented as containing "dangerous functionality" or using third-party libraries considered to be "risky components". This could include techniques such as sandboxing, encapsulation…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 2 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-15.2.5: Additional Protections Around Dangerous Functionality
+
+### Findings for 15.2.5
+
+### [MEDIUM]
+
+**Finding ID:** ASVS-1525-MED-001
+
+**Title:** No Sandboxing or Isolation for Cryptographic and Sensitive Election Operations
+
+**File:** `v3/steve/election.py` (entire module), `v3/server/pages.py` (entire module)
+
+**Issue:** The application contains highly sensitive functionality (cryptographic vote encryption/decryption, election state management, tamper detection) that runs within the same process and trust boundary as the web server and administrative functions. There is no evidence of:
+
+1. **Process isolation**: Cryptographic operations (`steve.crypto`) run in the same process as the web handler
+2. **Network isolation**: Admin endpoints (`/do-open/<eid>`, `/do-close/<eid>`, `/do-delete-issue/`) are served by the same application instance as voter endpoints (`/do-vote/<eid>`)
+3. **Containerization**: No Docker/container configuration visible
+4. **Privilege separation**: The `open()`, `close()`, and `tally_issue()` methods (which handle cryptographic material) execute with the same privileges as `serve_static()`
+5. **File system isolation**: `serve_doc()` accesses the filesystem from the same context that handles election encryption keys
+
+**Relevant dangerous operations:**
+- `election.open(pdb)` — generates cryptographic salts and opened_key (`election.py` line 70)
+- `election.add_vote()` — encrypts votes (`election.py` line 231)
+- `election.tally_issue()` — decrypts all votes (`election.py` line 248)
+- `serve_doc()` — serves files from filesystem (`pages.py` line 560)
+
+**Impact:** If an attacker compromises one part of the application (e.g., through the document serving endpoint or a template injection), they could pivot to access cryptographic keys, decrypt votes, or tamper with elections.
+
+**Remediation:**
+1. Separate admin/management functions from voter-facing endpoints into distinct services
+2. Run cryptographic operations (tally, vote encryption) in an isolated subprocess or container
+3. Use network policies to restrict which components can access the database directly
+4. Implement least-privilege access: the web-facing service should not have direct access to `opened_key` values
+5. Example architecture:
+```
+[Voter Service] → [Vote API] → [Crypto Service (isolated)]
+                                        ↓
+[Admin Service] → [Admin API] → [Election DB (restricted)]
+```
+
+---
+
+### [MEDIUM]
+
+**Finding ID:** ASVS-1525-MED-002
+
+**Title:** State-Changing Operations Exposed via GET Requests Without CSRF Protection
+
+**File:** `v3/server/pages.py`, lines 431-466
+
+**Vulnerable code:**
+```python
+@APP.get('/do-open/<eid>')
+@asfquart.auth.require({R.committer})  ### need general solution
+@load_election
+async def do_open_endpoint(election):
+    # ...
+    election.open(pdb)
+    # ...
+
+@APP.get('/do-close/<eid>')
+@asfquart.auth.require({R.committer})  ### need general solution
+@load_election
+async def do_close_endpoint(election):
+    # ...
+    election.close()
+    # ...
+```
+
+**Data flow:** Browser GET request (or attacker-controlled link/img src) → no CSRF validation → permanent election state change
+
+**Proof of Concept:**
+```html
+<img src="https://steve.apache.org/do-open/a1b2c3d4e5" />
+<img src="https://steve.apache.org/do-close/a1b2c3d4e5" />
+```
+
+**Issue:** Opening and closing elections are irreversible operations performed via GET requests with no CSRF protection. Combined with the placeholder CSRF token (`basic.csrf_token = 'placeholder'`), these "dangerous functions" have no additional protection layer.
+
+**Impact:** An attacker can permanently open or close an election by tricking an authenticated admin into visiting a page with a crafted image tag or link.
+
+**Remediation:** Convert to POST with CSRF validation:
+```python
+@APP.post('/do-open/<eid>')
+@asfquart.auth.require({R.committer})
+@load_election
+async def do_open_endpoint(election):
+    validate_csrf_token(await quart.request.form)
+    # ... proceed with opening
+```
+
+### Security Controls Inventory for 15.2.5
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Process isolation/sandboxing | Not present | Missing |
+| Network isolation | Not present | Missing |
+| Containerization | Not present | Missing |
+| Privilege separation | Not present | Missing |
+| CSRF protection for dangerous ops | `pages.py` line 83 | Placeholder only |
+| State assertions before operations | `election.py` multiple lines | Present (but `assert` can be disabled) |
+| Authentication requirement | `pages.py` decorators | Present |
+
+### Positive Patterns for 15.2.5
+
+- Election state machine enforces that operations can only occur in appropriate states (editable → open → closed)
+- The `is_tampered()` method provides detection of unauthorized modifications to election data
+- The `_all_metadata(required_state=...)` pattern prevents operations in wrong states
+- Cryptographic vote shuffling prevents database-order information leakage
+- Delete operations are wrapped in transactions with referential integrity ordering
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Authentication vs. Authorization Gap**: The application has authentication (`@asfquart.auth.require`) but lacks fine-grained authorization. All committers can manage any election — there are multiple `### check authz` placeholder comments indicating this is known but unimplemented. This creates a horizontal privilege escalation risk.
+
+2. **CSRF Protection Entirely Missing**: The `csrf_token = 'placeholder'` on line 83 of `pages.py` means every state-changing endpoint is vulnerable to CSRF. This affects multiple requirements:
+   - 15.2.5: No protection for dangerous operations (open/close election)
+   - 15.3.3: Mass assignment protection is weakened when attackers can submit forms cross-origin
+
+3. **Defense in Depth Architecture**: The application relies on a single-layer architecture where the web server, business logic, and cryptographic operations all run in the same process. This maximizes blast radius from any single vulnerability.
+
+4. **State Machine as Security Control**: The `assert`-based state machine in `election.py` (editable → open → closed) provides an important security boundary. However, `assert` statements can be disabled with Python's `-O` flag, making this a fragile control for production.
+
+5. **Query Design Philosophy**: The codebase shows two competing patterns — some queries (external-facing) explicitly select safe columns, while others (internal) use `SELECT *`. This split is well-documented but creates maintenance risk.
+
+6. **Session-Based Identity**: The consistent use of `result.uid` from authenticated sessions for identity (rather than client-supplied values) is a strong positive pattern across all endpoints.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical/High Priority)
+1. **Implement CSRF protection**: Replace `'placeholder'` with actual token generation and validation on all state-changing endpoints
+2. **Convert GET state-changers to POST**: `/do-open/<eid>` and `/do-close/<eid>` must be POST endpoints
+3. **Implement authorization checks**: Fill in all `### check authz` placeholders — at minimum, verify that the authenticated user is the election owner before allowing management operations
+4. **Replace `assert` with explicit checks**: State validation should use `if not ... : raise` rather than `assert` which can be optimized away
+
+### Short-term (Medium Priority)
+5. **Configure trusted proxy middleware**: Add ProxyFix or equivalent with appropriate trust depth
+6. **Add IP addresses to audit logs**: Include client IP (from trusted proxy chain) in security-relevant log entries
+7. **Replace `SELECT *` queries**: Use explicit column lists in all queries, especially those touching tables with cryptographic material
+8. **Implement formal input schemas**: Add dataclass or Pydantic-based input validation with explicit field allowlists
+9. **Remove debug print statements**: Replace with structured logging at appropriate levels
+10. **Pin dependency sources**: Add repository configuration and generate/commit lock file with hashes
+
+### Long-term (Architecture)
+11. **Service separation**: Split admin, voter, and cryptographic operations into separate services with network isolation
+12. **Containerization**: Deploy with container-level isolation between components
+13. **Least privilege**: The crypto/tally service should be the only component with access to opened_key values
+14. **Rate limiting**: Implement rate limiting using correctly-resolved client IPs
+15. **Dependency scanning**: Integrate automated dependency vulnerability scanning (e.g., `pip-audit`, `safety`) into CI/CD
+        
\ 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