You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tooling.apache.org by as...@apache.org on 2026/05/05 12:17:39 UTC
(tooling-agents) branch main updated: ASVS audit: 6.6.1.md (redacted)
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 9ee3f3e ASVS audit: 6.6.1.md (redacted)
9ee3f3e is described below
commit 9ee3f3e9231f62b4fc8a59a64db2059c5c1672c4
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:09:11 2026 +0200
ASVS audit: 6.6.1.md (redacted)
---
ASVS/reports/steve/v3/d0aa7e9/all/6.6.1.md | 115 +++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.6.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.6.1.md
new file mode 100644
index 0000000..583601f
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.6.1.md
@@ -0,0 +1,115 @@
+# Security Audit Report: ASVS 6.6.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.6.1 |
+| **Files Analyzed** | 4 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that authentication mechanisms using the Public Switched Telephone Network (PSTN) to deliver One-time Passwords (OTPs) via phone or SMS are offered only when the phone number has previously been validated, alternate stronger methods (such as Time based One-time Passwords) are also offeredβ¦
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| π΄ Critical | 0 |
+| π High | 0 |
+| π‘ Medium | 1 |
+| π’ Low | 0 |
+
+---
+
+## ASVS-6.6.1: PSTN/SMS OTP Restrictions
+
+### Findings for 6.6.1
+
+No SMS, phone, or PSTN-based OTP delivery mechanisms are implemented in this codebase. The application does not send any one-time passwords via any channel.
+
+**Assessment**: For an L3 application (which a voting system should be), phone and SMS must not be available as authentication options. Since authentication is delegated to `asfquart.auth`, compliance depends on the external system's configuration. The audited code neither offers nor restricts PSTN-based OTP.
+
+### [MEDIUM]
+
+**Finding ID**: ASVS-661-MED-001
+
+**Location**: `v3/server/pages.py`, function `basic_info()`, line 83
+
+**Description**: The application is a sensitive voting system that delegates all authentication to an external framework without any visible enforcement or verification that the external authentication provider does not use SMS/PSTN as a sole MFA factor. For L3 compliance, the application should verify or enforce that restricted authenticators are not in use.
+
+```python
+# pages.py line 83
+### generate a real token and store in the session
+basic.csrf_token = 'placeholder'
+```
+
+**Data flow**: External auth provider β `asfquart.auth.require` β session established β no verification of authentication strength
+
+**Impact**: If the external `asfquart` authentication system allows SMS-based MFA, voters in a sensitive election could be authenticated via a deprecated/restricted mechanism vulnerable to SIM-swap, number porting, and interception attacks.
+
+**Remediation**: Verify at the application layer that the authentication assurance level meets L3 requirements:
+
+```python
+async def basic_info():
+ s = await asfquart.session.read()
+ if s:
+ # Verify authentication strength for L3
+ auth_method = s.get('auth_method', '')
+ if auth_method in ('sms', 'phone', 'pstn'):
+ quart.abort(403, 'SMS/Phone authentication is not permitted for this application')
+```
+
+### Security Controls Inventory for 6.6.1
+
+| Control | Location | Coverage |
+|---------|----------|----------|
+| Authentication delegation | `pages.py` (`@asfquart.auth.require`) | No verification of authentication method/strength |
+| No SMS/phone code in app | Entire codebase | Application does not implement its own OTP delivery |
+
+### Positive Patterns for 6.6.1
+
+- The application does not implement any SMS or phone-based OTP delivery, eliminating the risk of insecure PSTN-based authentication within its own code.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Complete Authentication Delegation**: The entire authentication and MFA stack is delegated to the external `asfquart.auth` framework. None of the ASVS 6.5.x or 6.6.x requirements can be fully verified from this codebase alone. The application trusts whatever session is established by the external authenticator without verifying authentication strength or method.
+
+2. **Sensitive Application Without Visible MFA Enforcement**: This is a voting/election system β inherently a high-sensitivity application that would classify as L3 under ASVS. Despite this, the application does not:
+ - Verify the authentication assurance level of the session
+ - Enforce step-up authentication for critical actions (opening/closing elections)
+ - Check whether the authenticated session used MFA at all
+
+3. **No Authentication Method Metadata**: The session data (`asfquart.session.read()`) appears to only provide `uid`, `fullname`, and `email`. There is no evidence that authentication method, assurance level, or MFA status is communicated from the auth provider to the application.
+
+4. **Critical Actions Without Re-authentication**: State-changing operations like opening an election (`/do-open/<eid>`) and closing an election (`/do-close/<eid>`) are performed via simple GET requests with no re-authentication, step-up authentication, or additional verification. For a voting system at L3, these operations should require fresh MFA verification.
+
+5. **CSRF Token Placeholder Compounds Risk**: The `csrf_token = 'placeholder'` issue (line 83 of `pages.py`) means that even if MFA were properly implemented at login time, session-riding attacks could perform critical election operations without any additional authentication challenge.
+
+## Cross-cutting Recommendations
+
+### Immediate
+1. **Verify external auth MFA compliance**: Audit the `asfquart.auth` framework to confirm it enforces MFA for all sessions, does not allow SMS/PSTN as sole second factor, uses server-side time for TOTP, and binds OOB codes to specific requests.
+
+2. **Implement authentication assurance level checks**: Add session metadata that communicates the authentication method and assurance level. Reject sessions that don't meet L3 requirements.
+
+### Short-term
+3. **Add step-up authentication for critical actions**: Require re-authentication (ideally with MFA) for irreversible operations like opening/closing elections.
+
+4. **Implement proper CSRF protection**: Replace the placeholder token with a real implementation to prevent session-riding attacks that bypass the MFA boundary.
+
+5. **Add rate limiting infrastructure**: Even though no OOB mechanisms exist in this code currently, add rate limiting middleware that can protect any future authentication endpoints.
+
+### Long-term
+6. **Document authentication architecture**: Create an architecture document that maps which ASVS MFA requirements are handled by which component (application vs. `asfquart` vs. identity provider), ensuring no gaps.
+
+7. **Consider WebAuthn/FIDO2**: For an L3 voting application, consider supporting phishing-resistant authentication (FIDO2/WebAuthn) which would satisfy multiple ASVS requirements simultaneously and provide stronger guarantees than TOTP or push-based MFA.
+
+8. **Implement authentication event logging**: Log the authentication method and MFA factors used for each session, enabling audit trail verification that L3-compliant methods are consistently used.
+
\ 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