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

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

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/6.3.7.md b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.7.md
new file mode 100644
index 0000000..b39f015
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/6.3.7.md
@@ -0,0 +1,153 @@
+# Security Audit Report: ASVS 6.3.7
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 6.3.7 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 1 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-6.3.7: Notification After Updates to Authentication Details
+
+### Findings for 6.3.7
+
+#### [MEDIUM] ASVS-637-MED-001
+**Finding:** No Notification System for Authentication Detail Changes
+
+**File:** `v3/server/pages.py`, lines 535-548 (profile/settings pages)
+
+**Vulnerable Code:**
+```python
+@APP.get('/profile')
+@asfquart.auth.require
+@APP.use_template(TEMPLATES / 'profile.ezt')
+async def profile_page():
+    result = await basic_info()
+    result.title = 'Profile'
+    return result
+
+@APP.get('/settings')
+@asfquart.auth.require
+@APP.use_template(TEMPLATES / 'settings.ezt')
+async def settings_page():
+    result = await basic_info()
+    result.title = 'Settings'
+    return result
+```
+
+**Description:** The application has profile and settings pages but no corresponding POST handlers for updating user details, and critically, no notification mechanism for when authentication details are modified. The `person` table in the schema contains `pid`, `name`, and `email`, and the `c_add_person` query in `queries.yaml` performs an UPSERT:
+
+```yaml
+c_add_person: |
+    INSERT INTO person VALUES (?, ?, ?)
+    ON CONFLICT DO UPDATE SET
+        name=excluded.name,
+        email=excluded.email
+```
+
+This means email can be changed without any notification being sent to the old or new email address. While credential management may be handled externally (via Apache LDAP), there is no integration point in this application for sending change notifications.
+
+**Impact:** If a user's authentication details (username, email) are changed — either through this system or the external identity provider — the user receives no notification, preventing detection of unauthorized account modifications.
+
+**Remediation:**
+```python
+@APP.post('/do-update-profile')
+@asfquart.auth.require
+async def do_update_profile():
+    result = await basic_info()
+    form = await quart.request.form
+    
+    old_email = result.email
+    new_email = form.get('email')
+    
+    if new_email and new_email != old_email:
+        # Notify BOTH old and new email
+        await send_notification(
+            old_email,
+            "Your email address has been changed",
+            f"Your email was changed to {new_email}. If you didn't do this, contact support."
+        )
+        await send_notification(
+            new_email,
+            "Email address verification",
+            "This email was added to your account."
+        )
+    
+    # Proceed with update...
+```
+
+---
+
+### Security Controls Inventory for 6.3.7
+
+| Control | Location | Status |
+|---------|----------|--------|
+| Email change notification | N/A | **NOT PRESENT** |
+| Password change notification | N/A | **NOT PRESENT** |
+| Profile update notification | N/A | **NOT PRESENT** |
+| Audit logging of detail changes | N/A | **NOT PRESENT** for person table changes |
+| `c_add_person` UPSERT | queries.yaml | Changes email silently |
+
+### Positive Patterns for 6.3.7
+
+- The email infrastructure (`asfpy.messaging`) exists and is functional, making it straightforward to add notifications.
+- Logging infrastructure is well-established for election operations and could be extended to person record changes.
+
+---
+
+
+
+## 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