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

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

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.3.6.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.6.md
new file mode 100644
index 0000000..04d4637
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.6.md
@@ -0,0 +1,89 @@
+# Security Audit Report: ASVS 6.3.6
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.3.6 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that email is not used as either a single-factor or multi-factor authentication mechanism.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.3.6: Email Not Used as Authentication Mechanism
+
+### Findings for 6.3.6
+
+No findings detected.
+
+### Security Controls Inventory for 6.3.6
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Authentication via `asfquart.auth` | pages.py, all protected endpoints | Session/role-based, not email-based |
+| Session data | `basic_info()` line 68 | Contains email field but for display only |
+| Email sending | `mail-voters.py` | Used for notifications only, not authentication |
+
+### Positive Patterns for 6.3.6
+
+- Email is stored in the session (`s['email']`) and person table but is only used for display and notification purposes.
+- The authentication mechanism uses `asfquart.auth.require` with role-based requirements (`R.committer`, `R.pmc_member`), not email-based login.
+- No magic link, email OTP, or email-based authentication flow exists in the codebase.
+- The `mail-voters.py` script sends notification emails about elections but does not create authentication tokens.
+- No endpoint accepts email as a login credential or authentication factor.
+
+---
+
+
+
+## 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