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

[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 56a7d34  ASVS audit: 3.5.4.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
56a7d34 is described below

commit 56a7d34c45af4dcc392c28736ca9b26f30d4e5ce
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:55:53 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/3.5.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/3.5.4.md
new file mode 100644
index 0000000..6fcc65f
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/3.5.4.md
@@ -0,0 +1,109 @@
+# Security Audit Report: ASVS 3.5.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 3.5.4 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that separate applications are hosted on different hostnames to leverage the restrictions provided by same-origin policy, including how documents or scripts loaded by one origin can interact with resources from another origin and hostname-based restrictions on cookies.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-3.5.4: Browser Origin Separation - Separate Hostnames
+
+### Findings for 3.5.4
+
+### [LOW]
+
+**Finding ID:** ASVS-354-LOW-001
+
+**Title:** Unable to Verify Hostname Separation — Single Application Serves All Functionality
+
+**File:** `v3/server/pages.py` (entire file)
+
+**Analysis:** The application serves administrative functions (`/admin`, `/manage`), voter functions (`/voter`, `/vote-on`), static files (`/static`), and document files (`/docs`) all from the same application instance. There is no evidence of:
+- Separate hostnames for admin vs. voter functionality
+- Separate origins for static content
+- Domain-based cookie scoping
+
+The code uses a single `APP` instance with all routes registered in one file, suggesting a single-origin deployment.
+
+**Impact:** If a vulnerability (e.g., XSS) exists in one area of the application, it can access cookies and data from all other areas since they share the same origin. Administrative session cookies are accessible from voter-facing pages and vice versa.
+
+**Remediation:** Consider separating administrative and voter functionality onto different subdomains:
+- `admin.steve.example.com` — Election management
+- `vote.steve.example.com` — Voter interface
+- `static.steve.example.com` — Static assets (with restrictive CSP)
+
+---
+
+### Security Controls Inventory for 3.5.4
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Hostname-based separation | Not found | **NOT IMPLEMENTED** |
+| Cookie domain scoping | Not visible in provided code | **UNKNOWN** |
+| Content Security Policy | Not visible in provided code | **UNKNOWN** |
+
+### Positive Patterns for 3.5.4
+
+- The application has distinct URL path prefixes for different functional areas (`/admin`, `/manage`, `/voter`, `/vote-on`)
+- Authentication requirements differ between areas (e.g., `R.pmc_member` for election creation vs `R.committer` for voting)
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **CSRF Protection is Entirely Absent Despite Apparent Intent:** The codebase shows clear architectural intent to implement CSRF protection (token fields in templates, header passing in fetch calls, TODO items acknowledging it), but the actual enforcement is completely missing. This creates a dangerous false sense of security — developers and reviewers may believe protection exists because they see the tokens in templates.
+
+2. **GET-Based State Changes Compound the CSRF Problem:** The `/do-open/<eid>` and `/do-close/<eid>` endpoints using GET method means that even implementing CSRF tokens for POST requests would leave these critical operations unprotected. These must be converted to POST before any CSRF solution is effective.
+
+3. **Authorization Model is Incomplete:** Multiple `### check authz` placeholders indicate that ownership verification (e.g., "does this user own this election?") is not enforced. Any authenticated committer can manage any election. While this is beyond the scope of ASVS 3.5.x, it amplifies the impact of CSRF — an attacker doesn't need to target the election owner specifically.
+
+4. **Template Security is Well-Implemented:** The use of `[format "js,html"]` in EZT templates for user-supplied data injected into JavaScript contexts shows awareness of XSS prevention, which is relevant because XSS can bypass CSRF protections.
+
+5. **Client-Server Contract Mismatch:** The client (templates) sends CSRF tokens and custom headers that the server completely ignores. This indicates the frontend was developed with security in mind but the backend implementation was deferred.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical — deploy blockers)
+
+1. **Implement CSRF token validation on all POST endpoints.** Generate a cryptographically random token per session, store it server-side, and validate it on every state-changing request. Use a decorator pattern for consistency.
+
+2. **Convert `/do-open/<eid>` and `/do-close/<eid>` from GET to POST.** These perform irreversible operations and must not be triggerable via simple navigation, image loads, or link prefetch.
+
+3. **Add Origin header validation** as defense-in-depth for all POST endpoints, rejecting requests with an Origin header that doesn't match the application's own origin.
+
+### Short-term (High priority — within sprint)
+
+4. **Enforce Content-Type validation** on form endpoints — reject requests that don't match `application/x-www-form-urlencoded` or `multipart/form-data` as appropriate. For JSON endpoints, reject non-`application/json` requests.
+
+5. **Configure SameSite=Lax (minimum) or SameSite=Strict on session cookies.** This provides browser-level CSRF protection for most scenarios while the token-based approach covers older browsers.
+
+6. **Add Sec-Fetch-Site header checking** as an additional defense layer — reject requests where `Sec-Fetch-Site: cross-site` on sensitive endpoints.
+
+### Long-term (Architecture improvements)
+
+7. **Consider hostname-based separation** for admin and voter functionality to leverage Same-Origin Policy restrictions between functional domains.
+
+8. **Implement a comprehensive security middleware stack** that handles CSRF, CORS, and Content-Type validation in one place rather than requiring per-endpoint implementation.
+
+9. **Add integration tests** that verify CSRF protection by attempting state-changing requests without valid tokens and asserting they fail with 403.
+        
\ 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