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

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

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.3.5.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.5.md
new file mode 100644
index 0000000..9486650
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.5.md
@@ -0,0 +1,134 @@
+# Security Audit Report: ASVS 6.3.5
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.3.5 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that users are notified of suspicious authentication attempts (successful or unsuccessful). This may include authentication attempts from an unusual location or client, partially successful authentication (only one of multiple factors), an authentication attempt after a long period of…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.3.5: Notification of Suspicious Authentication Attempts
+
+### Findings for 6.3.5
+
+#### [MEDIUM] ASVS-635-MED-001
+**Finding:** No Suspicious Authentication Attempt Detection or Notification
+
+**File:** `v3/server/pages.py` (entire file scope)
+
+**Description:** The application contains no mechanism to detect or notify users of suspicious authentication attempts. The codebase was thoroughly searched for:
+
+- Login attempt tracking — **Not found**
+- Geolocation/IP-based anomaly detection — **Not found**
+- Failed authentication counting — **Not found**
+- Notification dispatch on suspicious events — **Not found**
+- Inactivity-based alerts — **Not found**
+- Partial authentication notifications (e.g., only one factor succeeded) — **Not found**
+
+The `basic_info()` function reads session data but does not track login metadata (IP, user agent, timestamp of last login). The logging infrastructure (`_LOGGER`) logs post-authentication actions but not authentication events themselves.
+
+The only notification-related code is `v3/server/bin/mail-voters.py`, which sends election notifications — not security alerts.
+
+**Impact:** Users would be unaware of unauthorized access attempts or account compromise, preventing timely response to attacks.
+
+**Remediation:**
+```python
+# In authentication middleware or post-login handler:
+async def post_login_check(session):
+    current_ip = quart.request.remote_addr
+    current_ua = quart.request.headers.get('User-Agent')
+    
+    last_login = await get_last_login(session['uid'])
+    
+    suspicious = False
+    if last_login:
+        if last_login.ip != current_ip:
+            suspicious = True
+        if (datetime.now() - last_login.timestamp).days > 90:
+            suspicious = True
+    
+    if suspicious:
+        await send_security_notification(
+            session['email'],
+            f"New login detected from {current_ip}"
+        )
+    
+    await record_login(session['uid'], current_ip, current_ua)
+```
+
+---
+
+### Security Controls Inventory for 6.3.5
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Login attempt tracking | N/A | **NOT PRESENT** |
+| IP/location anomaly detection | N/A | **NOT PRESENT** |
+| Security notification dispatch | N/A | **NOT PRESENT** |
+| Failed auth attempt counter | N/A | **NOT PRESENT** |
+| Last-login recording | N/A | **NOT PRESENT** |
+| Session metadata storage | `basic_info()` line 68 | Partial (no IP/timestamp tracking) |
+
+### Positive Patterns for 6.3.5
+
+- The application has a comprehensive logging infrastructure (`_LOGGER`) that records user actions with UIDs, which could serve as the foundation for anomaly detection.
+- Email infrastructure exists (`mail-voters.py`, `asfpy.messaging`) and could be reused for security notifications.
+
+---
+
+
+
+## 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