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

commit f9796877c0a541066e182dd01caa0c478f3c6fc4
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:08:38 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.3.3.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.3.md
new file mode 100644
index 0000000..daea880
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.3.md
@@ -0,0 +1,133 @@
+# Security Audit Report: ASVS 6.3.3
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.3.3 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that either a multi-factor authentication mechanism or a combination of single-factor authentication mechanisms, must be used in order to access the application. For L3, one of the factors must be a hardware-based authentication mechanism which provides compromise and impersonation…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 1 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.3.3: Multi-factor Authentication Mechanism
+
+### Findings for 6.3.3
+
+#### [HIGH] ASVS-633-HIGH-001
+**Finding:** No Multi-Factor Authentication Enforcement
+
+**File:** `v3/server/pages.py`, lines 35, 133-163, 221-276
+
+**Vulnerable Code:**
+```python
+@APP.get('/voter')
+@asfquart.auth.require({R.committer})  ### need general solution
+@APP.use_template(TEMPLATES / 'voter.ezt')
+async def voter_page():
+    result = await basic_info()
+    ...
+```
+
+**Data flow:** User request → `@asfquart.auth.require({R.committer})` → session check → access granted (single factor only)
+
+**Description:** The application relies exclusively on `asfquart.auth.require` with `R.committer` or `R.pmc_member` roles. The `basic_info()` function (line 68) reads session data containing `uid`, `fullname`, and `email`, but there is no evidence of a second authentication factor being required or verified anywhere in the authentication flow. All 15+ protected endpoints grant access based solely on a single-factor session credential (likely Apache LDAP/OAuth).
+
+The application manages sensitive election data (votes, election lifecycle) and allows irreversible state changes (opening/closing elections). For a L2 application, MFA must be enforced.
+
+**Impact:** If an attacker compromises a single credential (e.g., session token, password), they gain full access to the application, including the ability to vote on behalf of the user, manage elections, and create/delete election issues.
+
+**Proof of Concept:** An attacker who obtains a valid session cookie (via XSS, session fixation, or credential theft) can access all protected endpoints without any additional authentication challenge.
+
+**Remediation:**
+```python
+# Add MFA verification to the session validation flow
+import asfquart.mfa  # hypothetical module
+
+async def basic_info():
+    basic = edict()
+    s = await asfquart.session.read()
+    if s:
+        # Verify MFA has been completed for this session
+        if not s.get('mfa_verified'):
+            quart.abort(403, 'MFA verification required')
+        basic.update(uid=s['uid'], name=s['fullname'], email=s['email'])
+    else:
+        basic.update(uid=None, name=None, email=None)
+    basic.csrf_token = generate_csrf_token(s)
+    return basic
+```
+
+---
+
+### Security Controls Inventory for 6.3.3
+
+| Control | Location | Status |
+|---------|----------|--------|
+| `@asfquart.auth.require({R.committer})` | pages.py, multiple endpoints | Applied (single-factor only) |
+| `@asfquart.auth.require({R.pmc_member})` | pages.py, line 410 | Applied (single-factor only) |
+| `@asfquart.auth.require` (bare) | pages.py, lines 535, 543, 560 | Applied (session-only) |
+| MFA verification | N/A | **NOT PRESENT** |
+| Session MFA flag check | N/A | **NOT PRESENT** |
+
+### Positive Patterns for 6.3.3
+
+- The application uses role-based access control (`R.committer`, `R.pmc_member`) which provides a foundation for layering MFA on top.
+- The session infrastructure (`asfquart.session.read()`) could be extended to include an `mfa_verified` flag.
+- The code comments (`### need general solution`) indicate awareness that the current auth scheme is incomplete.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Authentication is externalized:** The actual login flow, credential verification, and session establishment are handled by `asfquart.auth` (not included in this codebase). Many ASVS 6.3 requirements would need to be assessed against that external system. The audited code only handles post-authentication authorization.
+
+2. **Authorization is the critical gap:** The most severe finding is the systematic failure to implement ownership-based authorization (Type B gap — control is intended but never implemented). This spans all management endpoints and creates a flat permission model where any committer can modify any election.
+
+3. **Separation of concerns:** The application cleanly separates:
+   - Authentication (external, via `asfquart.auth`)
+   - Session management (via `asfquart.session`)
+   - Business logic (via `steve.election.Election`)
+   - Cryptographic vote privacy (via `steve.crypto`)
+   
+   However, the authorization layer between authentication and business logic is entirely missing.
+
+4. **Security-conscious cryptographic design:** The election system has sophisticated anti-tamper mechanisms (`is_tampered()`), vote encryption, and privacy-preserving tallying. This contrasts sharply with the weak authentication/authorization controls.
+
+5. **TODO.md as documentation:** The application's own TODO file acknowledges CSRF and authorization gaps, confirming these are known issues awaiting resolution rather than oversights.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical Risk)
+1. **Implement authorization checks** at all `### check authz` locations. Verify election ownership (`md.owner_pid == current_uid`) or group membership (`user in md.authz group`) before allowing management operations.
+2. **Enforce MFA** via the external authentication provider or add an application-level MFA step after initial authentication.
+
+### Short-term (High Risk)
+3. **Implement CSRF protection** — replace the placeholder token with real per-session cryptographic tokens and validate on all state-changing endpoints.
+4. **Change GET to POST** for state-changing operations (`/do-open/<eid>`, `/do-close/<eid>`) to prevent CSRF via simple link injection.
+5. **Add audit logging** for person record changes and authentication events.
+
+### Long-term (Medium Risk)
+6. **Implement suspicious login detection** — track login metadata (IP, user agent, timestamp) and notify users of anomalies.
+7. **Add credential change notifications** — send email alerts when person records are modified.
+8. **Document all authentication pathways** formally, including the external auth provider's capabilities, MFA support, and integration points.
+9. **Implement rate limiting** on authentication-related endpoints to prevent brute-force attacks (per NIST SP 800-63B § 5.2.2).
+        
\ 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