(tooling-agents) branch main updated: ASVS audit: 10.4.1.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 f9faeb1  ASVS audit: 10.4.1.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
f9faeb1 is described below

commit f9faeb1c9738a6325a18ed7d54d790d84079ada7
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:51:00 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/10.4.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/10.4.1.md
new file mode 100644
index 0000000..883c6f1
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/10.4.1.md
@@ -0,0 +1,91 @@
+# Security Audit Report: ASVS 10.4.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 10.4.1 |
+| **Files Analyzed** | 4 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the authorization server validates redirect URIs based on a client-specific allowlist of pre-registered URIs using exact string comparison.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-10.4.1: OAuth Authorization Server - Redirect URI Validation
+
+### Findings for 10.4.1
+
+No findings detected.
+
+The codebase does not implement an OAuth authorization server. There are no authorization endpoints, no redirect_uri parameters, and no OAuth grant flows. This requirement is not applicable to the current codebase.
+
+### Security Controls Inventory for 10.4.1
+
+No applicable controls in this scope. The application is a web application with server-side rendered pages and form-based interactions, not an OAuth authorization server.
+
+### Positive Patterns for 10.4.1
+
+- The application uses server-side redirects with hardcoded paths (e.g., `quart.redirect(f'/manage/{election.eid}', code=303)`), which avoids open redirect vulnerabilities that would be analogous to redirect_uri manipulation.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **No OAuth Implementation Present:** The entire codebase uses traditional session-cookie-based authentication via `asfquart.session.read()` and role-based decorators. There is no OAuth 2.0 resource server or authorization server functionality. The ASVS 10.3.x and 10.4.x requirements are architecturally not addressed because the application doesn't implement the OAuth protocol at all.
+
+2. **Authorization Model Gap (Type B — Critical Pattern):** The most significant security concern across requirements is the repeated `### check authz` placeholder pattern. The code has **identified** where authorization checks should exist but has **not implemented** them. This creates a false sense of security. Any authenticated committer can manage any election (open, close, add issues, set dates), which represents a horizontal privilege escalation vulnerability.
+
+3. **Single Authentication Context:** The user identity (`result.uid`) flows from a single session source through all operations. There is no federation, no multi-issuer support, and no delegation model. This simplifies the security model but means the application cannot enforce OAuth-style delegated authorization if it needs to be accessed by third-party clients.
+
+4. **Election-Level Access Control Done Right in Some Places:** The `vote_on_page()` handler and `serve_doc()` handler properly check voter eligibility via `q_find_issues` and `q_get_mayvote` respectively. However, administrative operations (open, close, add/edit/delete issues) lack equivalent ownership checks.
+
+5. **Cryptographic Voter Anonymity vs. Authentication:** The voting system employs strong cryptographic measures (vote tokens, encryption, salts) to ensure ballot secrecy. However, the authentication layer protecting these operations is comparatively weaker (session cookies without binding, no MFA requirement, no freshness checks).
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical)
+
+1. **Implement Authorization Ownership Checks:** Replace all `### check authz` placeholders with actual ownership verification:
+   - Verify `election.get_metadata().owner_pid == result.uid` OR user is in the election's `authz` group
+   - Apply to: `/do-open/`, `/do-close/`, `/do-add-issue/`, `/do-edit-issue/`, `/do-delete-issue/`, `/do-set-open_at/`, `/do-set-close_at/`
+   - **Priority:** This is exploitable today by any authenticated committer
+
+2. **Implement CSRF Protection:** Replace `basic.csrf_token = 'placeholder'` with actual CSRF token generation and validation. All POST endpoints and state-changing GET endpoints (`/do-open/`, `/do-close/`) are vulnerable.
+
+### Short-term (High)
+
+3. **Add Authentication Freshness for Sensitive Operations:** For vote casting and election state changes, require that the authentication occurred within a recent time window (e.g., 10–30 minutes).
+
+4. **Convert State-Changing GETs to POSTs:** `/do-open/<eid>` and `/do-close/<eid>` use GET method for state-changing operations, making them susceptible to CSRF via image tags or link prefetching. Convert to POST with CSRF tokens.
+
+5. **If OAuth API Access Is Planned:** Design and implement an OAuth resource server layer with:
+   - JWT validation (signature, expiration, audience, issuer)
+   - Scope-based access control for API operations
+   - `sub` + `iss` based user identification
+
+### Long-term (Strategic)
+
+6. **Evaluate OAuth/OIDC Integration:** If this voting system needs to support API clients or federated access, implement:
+   - An OAuth resource server with token introspection or JWT validation
+   - Sender-constrained tokens (DPoP) for Level 3 compliance
+   - Step-up authentication for high-sensitivity operations (vote casting)
+
+7. **Implement Audit Logging with Authentication Context:** Log authentication method and strength alongside actions to support forensic analysis and compliance verification.
+        
\ 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