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

commit 005cf0ae099db6bdefc2af8f2956e90cd326da9e
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:10:30 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/9.2.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/9.2.4.md
new file mode 100644
index 0000000..a298c54
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/9.2.4.md
@@ -0,0 +1,89 @@
+# Security Audit Report: ASVS 9.2.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 9.2.4 |
+| **Files Analyzed** | 5 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-9.2.4: Audience Restriction in Issued Tokens
+
+### Findings for 9.2.4
+
+No findings detected.
+
+**Rationale**: This application is a **token consumer**, not a token issuer. It does not issue self-contained tokens (JWTs or similar) to different audiences. The tokens it generates internally are:
+
+1. **Vote tokens** (`vote_token`): 32-byte Argon2 hashes stored in the database, derived from `(opened_key, pid, iid, salt)`. These are not transmitted to external services.
+2. **Session tokens**: Managed by `asfquart.session`, which is an external framework component.
+3. **CSRF tokens**: Currently a placeholder, not a cryptographic token.
+
+None of these are issued to multiple audiences using a shared private key. The ASVS 9.2.4 requirement about token issuers using the same private key for different audiences is not applicable to this codebase.
+
+### Security Controls Inventory for 9.2.4
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Token issuance with audience restriction | N/A | Not applicable — application is not a token issuer for multiple audiences |
+| Vote token scoping | `crypto.gen_vote_token(opened_key, pid, iid, salt)` in `election.py` | Each vote_token is inherently scoped to a specific (election, person, issue) tuple |
+
+### Positive Patterns for 9.2.4
+
+1. **Vote tokens are inherently audience-restricted**: Each `vote_token` is derived from `(opened_key, pid, iid, salt)` where:
+   - `opened_key` is unique per election (derived from election-specific data)
+   - `pid` is unique per person
+   - `iid` is unique per issue
+   - `salt` is unique per person-issue pair
+   
+   This means a vote_token generated for one election/issue/person cannot be reused for another combination — it naturally embeds audience restrictions.
+
+2. **Election-scoped cryptographic material**: The `opened_key` is unique to each election (derived via Argon2 from `gather_election_data()` which includes all election metadata, issues, and voter information). This prevents cross-election token reuse.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Single-service architecture**: This is a monolithic web application, not a microservices system. The ASVS 9.2.x requirements about token type/audience validation are primarily designed for distributed systems where tokens flow between services. The relevance is reduced (but not eliminated) for this architecture.
+
+2. **Authentication delegation**: All authentication and session management is delegated to `asfquart.session` and `asfquart.auth`. The security posture of the application heavily depends on the correctness of these external modules, which are not in scope for this audit.
+
+3. **Internal token design is sound**: The `vote_token` system demonstrates good cryptographic design — tokens are derived from multiple inputs making them naturally scoped and resistant to cross-purpose reuse.
+
+4. **Authorization gaps more critical than token issues**: The repeated `### check authz` placeholders throughout the code represent a more immediate threat than token validation issues. Any authenticated committer can manage/open/close/delete any election.
+
+5. **CSRF as a token validation failure**: The placeholder CSRF token represents a concrete failure to validate a security token for its intended purpose (9.2.2), but the root cause is incomplete implementation rather than a design flaw.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical)
+1. **Implement CSRF token validation**: Replace the placeholder with a cryptographically random token stored in the session, validated on all state-changing endpoints.
+2. **Implement authorization checks**: Replace all `### check authz` placeholders with actual ownership/permission validation to ensure only election owners can manage their elections.
+
+### Short-term (High)
+3. **Document and verify framework token validation**: Audit `asfquart.auth` to confirm it validates token type and audience claims (if using JWTs/OIDC). Document the validation chain.
+4. **Add audience configuration**: If the ASF OAuth system issues tokens for multiple services, configure this application with an expected audience identifier and validate it.
+
+### Long-term (Medium)
+5. **Security architecture documentation**: Document the complete authentication and authorization flow, including which components validate which token properties, to enable future audits.
+6. **Consider token binding**: If transitioning to token-based authentication, implement sender-constrained tokens (DPoP or mTLS) to prevent token theft and replay across services.
+        
\ 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