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

commit f0be988956ae5f65c2390e20468717465e2bca1a
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:09:26 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.8.4.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.8.4.md
new file mode 100644
index 0000000..5898996
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.8.4.md
@@ -0,0 +1,194 @@
+# Security Audit Report: ASVS 6.8.4
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.8.4 |
+| **Files Analyzed** | 6 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that, if an application uses a separate Identity Provider (IdP) and expects specific authentication strength, methods, or recentness for specific functions, the application verifies this using the information returned by the IdP. For example, if OIDC is used, this might be achieved by…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 1 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.8.4: Authentication with Identity Provider - Authentication Strength Verification
+
+### Findings for 6.8.4
+
+#### [HIGH]
+
+**Finding ID**: ASVS-684-HIGH-001
+
+**Title**: No verification of authentication strength, method, or recentness from IdP
+
+**File**: `v3/server/pages.py` (lines 68-83, and all protected endpoints)
+
+**Vulnerable code**:
+```python
+async def basic_info():
+    """Return base-level EZT template data."""
+    basic = edict()
+    s = await asfquart.session.read()
+    if s:
+        basic.update(
+            uid=s['uid'],
+            name=s['fullname'],
+            email=s['email'],
+        )
+    # No validation of acr, amr, auth_time claims
+    # No check of authentication strength or recentness
+```
+
+**Data flow**: IdP authentication → session (no strength metadata captured) → sensitive operations (election open/close, voting) performed without strength verification
+
+**Description**: The application performs sensitive operations (opening/closing elections, casting votes, managing voter rolls) without any verification of:
+1. **Authentication Context Class Reference (acr)**: No check of what level of authentication was used
+2. **Authentication Methods References (amr)**: No verification of whether MFA was used
+3. **Authentication time (auth_time)**: No check of how recently the user authenticated
+
+Critical operations like `do_open_endpoint` (which commits an election to voting), `do_vote_endpoint` (which casts irreversible votes), and `do_close_endpoint` (which finalizes election results) all proceed with only a basic session check.
+
+There is no documented fallback approach that assumes minimum-strength authentication.
+
+**Impact**: An attacker who compromises a user's session through a weaker authentication path (e.g., stolen session cookie, single-factor auth when MFA should be required) can perform all privileged operations including:
+- Opening elections for voting
+- Casting votes on behalf of the compromised user
+- Closing elections and finalizing results
+- Creating new elections
+
+**Proof of Concept**: 
+1. User authenticates via a weak mechanism (e.g., password-only without MFA)
+2. User navigates to `/do-open/<eid>` (a GET request with no additional protection)
+3. Election is permanently opened without any step-up authentication check
+
+**Remediation**:
+```python
+async def require_strong_auth():
+    """Verify authentication strength for sensitive operations."""
+    s = await asfquart.session.read()
+    if not s:
+        quart.abort(401)
+    
+    # Check authentication recentness (e.g., within last 5 minutes for critical ops)
+    auth_time = s.get('auth_time')
+    if auth_time:
+        age = time.time() - auth_time
+        if age > 300:  # 5 minutes
+            # Require re-authentication
+            return quart.redirect('/reauth?return_to=' + quart.request.path)
+    
+    # Check authentication method
+    amr = s.get('amr', [])
+    if 'mfa' not in amr and 'otp' not in amr:
+        # Fallback: assume single-factor, restrict operations
+        quart.abort(403, 'Multi-factor authentication required for this operation')
+    
+    return s
+
+# Apply to sensitive operations
+@APP.get('/do-open/<eid>')
+@asfquart.auth.require({R.committer})
+@load_election
+async def do_open_endpoint(election):
+    s = await require_strong_auth()
+    # ... proceed with opening
+```
+
+#### [MEDIUM]
+
+**Finding ID**: ASVS-684-MED-002
+
+**Title**: State-changing operations via GET request without re-authentication
+
+**File**: `v3/server/pages.py` (lines 431-465)
+
+**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)  # Irreversible state change via GET
+
+@APP.get('/do-close/<eid>')
+@asfquart.auth.require({R.committer})  ### need general solution
+@load_election
+async def do_close_endpoint(election):
+    # ...
+    election.close()  # Irreversible state change via GET
+```
+
+**Description**: Critical, irreversible operations (opening and closing elections) are performed via GET requests with no step-up authentication or confirmation. Combined with the lack of CSRF protection (placeholder token), these endpoints are vulnerable to CSRF attacks through simple link/image tags, and no authentication recentness check is performed.
+
+**Impact**: An attacker can trick an authenticated user into opening or closing an election by having them visit a malicious page containing `<img src="https://voting.example.org/do-open/target_eid">`.
+
+**Remediation**: Convert to POST with CSRF protection and add re-authentication for critical operations.
+
+### Security Controls Inventory for 6.8.4
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Authentication recentness check | Not present | **MISSING** |
+| Authentication method verification (amr) | Not present | **MISSING** |
+| Authentication context class (acr) | Not present | **MISSING** |
+| Step-up authentication for critical ops | Not present | **MISSING** |
+| Documented fallback for auth strength | Not present | **MISSING** |
+| Session-based auth | `asfquart.session.read()` | Present but lacks strength metadata |
+
+### Positive Patterns for 6.8.4
+
+- The system does differentiate between authorization levels (`R.committer` vs `R.pmc_member`) for different operations
+- Election state assertions (`is_editable()`, `is_open()`) prevent operations in wrong states
+- All sensitive endpoints require authentication (no accidentally public endpoints)
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Single Trust Boundary**: The application places complete trust in the `asfquart` authentication framework. There is no defense-in-depth for authentication - if the framework is bypassed, all controls fail simultaneously.
+
+2. **Cryptographic Architecture vs. Authentication Architecture Mismatch**: The election voting system has sophisticated cryptographic protections (Argon2 hashing, per-voter salts, Fernet encryption, anti-tamper detection), but the authentication and authorization layer is incomplete with numerous `### check authz` placeholder comments.
+
+3. **No Separation of Duties**: The same `R.committer` role can both manage elections and vote in them. There is no enforcement that the election owner cannot also modify votes or bypass the anti-tamper mechanism.
+
+4. **CSRF Protection Gap**: The placeholder CSRF token (`'placeholder'`) means that even with proper IdP integration, session-based attacks remain possible across all POST endpoints and the GET-based state-changing endpoints (`/do-open/`, `/do-close/`).
+
+5. **Opaque Authentication Dependencies**: The security posture of the application is heavily dependent on the `asfquart` library, which is not included in the audit scope. The application cannot be fully assessed for ASVS 6.8.x requirements without visibility into this dependency.
+
+6. **Authorization is Role-Based Only**: The system checks if a user is a "committer" or "pmc_member" but does not check if they are the *owner* of a specific election or have been specifically authorized for it. Any committer can manage any election.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical Priority)
+1. **Implement CSRF protection**: Replace the placeholder token with a real CSRF mechanism. This affects all POST endpoints and the GET-based state-changing endpoints.
+2. **Convert state-changing GET endpoints to POST**: `/do-open/<eid>` and `/do-close/<eid>` must not use GET for irreversible operations.
+3. **Implement authorization checks**: Replace all `### check authz` placeholders with actual ownership/permission verification before allowing election management operations.
+
+### Short-term (High Priority)
+4. **Add authentication strength verification**: Capture and validate `acr`, `amr`, and `auth_time` from the IdP for sensitive operations (election open/close, vote submission).
+5. **Namespace user identities by IdP**: Add an IdP identifier to the `person.pid` to prevent future identity collision if multiple IdPs are supported.
+6. **Document authentication framework requirements**: Create explicit documentation of what `asfquart.auth` must verify (signature validation, replay prevention, token expiry) as a contractual interface.
+7. **Add database integrity protection**: Implement an HMAC or signature over the `opened_key` to detect unauthorized modification at the database level.
+
+### Long-term (Architectural)
+8. **Implement step-up authentication**: For critical operations (opening/closing elections), require re-authentication or MFA verification.
+9. **Add audit logging for authentication events**: Log authentication method, strength, and time for security monitoring.
+10. **Consider database encryption**: Protect the SQLite database at rest to prevent direct modification of cryptographic material.
+11. **Implement proper secret management**: The cryptographic keys and salts should be managed according to the "Secret Management" principles referenced in the ASVS section description, potentially using a dedicated key management service.
+        
\ 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