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/04/22 13:46:00 UTC
(tooling-agents) branch main updated: ASVS L3 audit: 6.3.7 (ch06_general)
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 dfbbde5 ASVS L3 audit: 6.3.7 (ch06_general)
dfbbde5 is described below
commit dfbbde55d7288bc5d9c5023b1df2fcafd7d64a7d
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Wed Apr 22 15:45:55 2026 +0200
ASVS L3 audit: 6.3.7 (ch06_general)
---
.../reports/steve/v3/d0aa7e9/ch06_general/6.3.7.md | 404 +++++++++++++++++++++
1 file changed, 404 insertions(+)
diff --git a/repos/apache/ASVS/reports/steve/v3/d0aa7e9/ch06_general/6.3.7.md b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/ch06_general/6.3.7.md
new file mode 100644
index 0000000..48a3f58
--- /dev/null
+++ b/repos/apache/ASVS/reports/steve/v3/d0aa7e9/ch06_general/6.3.7.md
@@ -0,0 +1,404 @@
+# ASVS 6.3.7 Security Audit Report
+
+## Executive Summary
+
+- **Repository:** apache/steve
+- **Audit Date:** Apr 22, 2026
+- **Auditor:** Tooling Agents
+- **ASVS Requirement:** 6.3.7 — Verify that users are notified after updates to authentication details, such as credential resets or modification of the username or email address (Level 3, General Authentication Security)
+- **Files Analyzed:** 3 relevant out of 49 total, 12 skipped
+- **Compliance Status:** ❌ **Non-Compliant** — Complete absence of user notification mechanisms for authentication detail updates
+
+### Finding Summary
+
+| Severity | Count | Description |
+|----------|-------|-------------|
+| Critical | 0 | No critical findings |
+| High | 0 | No high severity findings |
+| Medium | 2 | Missing notification infrastructure and silent email updates |
+| Low | 0 | No low severity findings |
+| **Total** | **2** | **All findings require remediation for ASVS 6.3.7 compliance** |
+
+### Key Findings
+
+Analysis reveals a **complete absence** of any notification mechanism when person/authentication details are modified, combined with a backend method that supports silent email address changes. The system lacks both notification infrastructure and audit logging for authentication detail modifications.
+
+---
+
+## Security Controls Inventory
+
+| Control | Defined? | Location | Applied? | Coverage |
+|---------|----------|----------|----------|----------|
+| User notification on email change | ❌ No | N/A | N/A | 0% — No notification infrastructure exists |
+| User notification on name change | ❌ No | N/A | N/A | 0% — No notification infrastructure exists |
+| User notification on credential reset | ❌ No | N/A | N/A | 0% — Auth is delegated to ASF OAuth; no local credential management |
+| Email sending capability | ❌ No | N/A | N/A | 0% — No email/messaging module in codebase |
+| Audit log of detail changes | ❌ No | `persondb.py:add_person` | N/A | 0% — No logging in `add_person` |
+
+---
+
+## Critical File Review
+
+### Files with Security-Sensitive Functions
+
+#### `v3/steve/persondb.py` — Person Data Management
+
+| Function | Lines | Purpose | ASVS 6.3.7 Status | Security Impact |
+|----------|-------|---------|-------------------|-----------------|
+| `add_person` | 46-51 | Add or update person records (email, name) | ❌ Non-compliant | Performs upserts without notification or logging |
+| Constructor | 39 | Initialize PersonDB queries | ⚠️ Partial | Comment shows security awareness ("NEVER return person.salt") |
+
+#### `v3/server/pages.py` — User Interface Endpoints
+
+| Function | Lines | Purpose | ASVS 6.3.7 Status | Security Impact |
+|----------|-------|---------|-------------------|-----------------|
+| `profile_page` | 578-583 | Display user profile page | ⚠️ Incomplete | GET-only; no update mechanism yet |
+| `settings_page` | 586-591 | Display user settings page | ⚠️ Incomplete | GET-only; no notification framework for future updates |
+| `basic_info` | 82+ | Retrieve session user info | N/A | Reads email from session but no change detection |
+
+#### `v3/steve/election.py` — Election Management
+
+| Function | Lines | Purpose | ASVS 6.3.7 Status | Security Impact |
+|----------|-------|---------|-------------------|-----------------|
+| `get_voters_for_email` | 510-516 | Retrieve voter email addresses | N/A | Demonstrates email is used for communications |
+
+---
+
+## Findings
+
+### MEDIUM Severity
+
+#### Finding ASVS-637-SEV-001: No User Notification When Person Details (Email/Name) Are Modified
+
+| Attribute | Details |
+|-----------|---------|
+| **Finding ID** | ASVS-637-SEV-001 |
+| **Severity** | MEDIUM |
+| **Gap Type** | Type A — Entry point with NO control |
+| **File** | `v3/steve/persondb.py` |
+| **Function** | `add_person` |
+| **Lines** | 46–51 |
+| **Related Functions** | `v3/steve/election.py:get_voters_for_email` (lines 510–516) |
+| **ASVS Requirement** | 6.3.7 (Level 3) |
+
+**Description:**
+
+The `add_person` method performs an upsert operation that can silently modify a user's email address without any notification to either the old or new email address. Email addresses are security-sensitive authentication details used for election-related communications, making silent modifications a security risk.
+
+**Vulnerable Code:**
+
+```python
+# v3/steve/persondb.py lines 46-51
+def add_person(self, pid, name, email):
+ "Add or update a Person designated by PID."
+
+ # If we ADD, then SALT will be NULL. If we UPDATE, then it will not
+ # be touched (it should be NULL).
+ self.c_add_person.perform(pid, name, email)
+```
+
+**Data Flow:**
+
+```
+CLI/Admin tool → PersonDB.add_person(pid, name, new_email)
+ → c_add_person (upsert query) → DB updated
+ → ❌ NO notification to user at old email
+ → ❌ NO notification to user at new email
+ → ❌ NO audit log entry generated
+```
+
+**Technical Analysis:**
+
+1. **Email is a security-sensitive field**: `election.py:get_voters_for_email()` (line 510) uses stored emails for election-related communications
+2. **Silent changes enable redirection attacks**: A silently changed email could redirect election notifications to an attacker
+3. **No change detection**: The method doesn't check if values actually changed before updating
+4. **No audit trail**: No logging exists in `add_person`, preventing administrative oversight
+
+**Proof of Concept:**
+
+```python
+pdb = PersonDB.open(db_path)
+# Silently change voter's email - NO notification sent
+pdb.add_person("victim_pid", "Victim Name", "attacker@evil.com")
+# Now get_voters_for_email() returns attacker's email for this voter
+# Legitimate user receives NO notification of the change
+```
+
+**Impact:**
+
+- ❌ **ASVS 6.3.7 Violation**: Users are not notified when authentication details (email) are modified
+- 🔓 **Silent Email Takeover**: Compromised admin could redirect election notifications without user awareness
+- 📝 **No Audit Trail**: Person detail modifications leave no log entries for security review
+- ⚠️ **Level 3 Non-Compliance**: Fails to meet ASVS Level 3 requirements for authentication detail change notifications
+
+**Remediation:**
+
+```python
+# v3/steve/persondb.py
+import logging
+
+_LOGGER = logging.getLogger(__name__)
+
+def add_person(self, pid, name, email):
+ "Add or update a Person designated by PID."
+
+ # Check if this is an update (person already exists)
+ existing = self.q_get_person.first_row(pid)
+
+ self.c_add_person.perform(pid, name, email)
+
+ if existing:
+ old_name, old_email = existing.name, existing.email
+ changes = []
+ if old_email != email:
+ changes.append(f'email: {old_email} → {email}')
+ if old_name != name:
+ changes.append(f'name: {old_name} → {name}')
+
+ if changes:
+ _LOGGER.info(
+ f'Person[P:{pid}] details updated: {", ".join(changes)}'
+ )
+ # Send notification to BOTH old and new email addresses
+ self._notify_detail_change(pid, old_email, email, changes)
+ else:
+ _LOGGER.info(f'Person[P:{pid}] created: {name}, {email}')
+
+def _notify_detail_change(self, pid, old_email, new_email, changes):
+ """Notify user at both old and new email about detail changes.
+
+ Per ASVS 6.3.7, users must be notified after updates to
+ authentication details.
+ """
+ # Implementation depends on email infrastructure
+ # Must notify old_email to alert legitimate user
+ # Must notify new_email to confirm the change
+ raise NotImplementedError("Email notification required for ASVS 6.3.7")
+```
+
+---
+
+#### Finding ASVS-637-SEV-002: Profile/Settings Pages Exist Without Update Notification Framework
+
+| Attribute | Details |
+|-----------|---------|
+| **Finding ID** | ASVS-637-SEV-002 |
+| **Severity** | MEDIUM |
+| **Gap Type** | Type A — Entry point with NO control |
+| **File** | `v3/server/pages.py` |
+| **Functions** | `profile_page` (line 578), `settings_page` (line 586) |
+| **Lines** | 578–591 |
+| **Related Functions** | `basic_info` (line 82) |
+| **ASVS Requirement** | 6.3.7 (Level 3) |
+
+**Description:**
+
+The application provides authenticated `/profile` and `/settings` endpoints, indicating user-facing profile management is an intended feature. However, no notification framework exists anywhere in the codebase to support ASVS 6.3.7 compliance when profile update functionality is implemented.
+
+**Vulnerable Code:**
+
+```python
+# v3/server/pages.py lines 578-591
+@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
+```
+
+**Technical Analysis:**
+
+1. **Existing infrastructure without notification capability**: Routes exist and are authenticated, but no notification framework is present
+2. **No email sending capability**: No email module, notification queue, or message templates exist
+3. **No pattern for developers**: When POST handlers are added, no infrastructure guides developers toward notification implementation
+4. **Email usage confirmed**: `get_voters_for_email()` in `election.py` shows emails are used for communications, making this a concrete gap
+
+**Impact:**
+
+- 🏗️ **Architectural Gap**: No notification infrastructure means ASVS 6.3.7 cannot be satisfied for any authentication detail modification
+- ⚠️ **Future Risk**: When profile editing is implemented, absence of notification patterns increases risk of non-compliant deployment
+- 📧 **Communication Channel Exists**: System stores and uses email addresses for election communications, but lacks security notification capability
+- ❌ **Level 3 Non-Compliance**: Infrastructure gap prevents compliance with Level 3 notification requirements
+
+**Remediation:**
+
+Implement a notification service that can be used across the application:
+
+```python
+# v3/steve/notifications.py
+import logging
+from enum import Enum
+
+_LOGGER = logging.getLogger(__name__)
+
+class NotificationType(Enum):
+ EMAIL_CHANGED = "email_changed"
+ NAME_CHANGED = "name_changed"
+ PROFILE_UPDATED = "profile_updated"
+
+async def notify_auth_detail_change(
+ pid: str,
+ change_type: NotificationType,
+ old_value: str,
+ new_value: str,
+ notify_emails: list[str],
+):
+ """Send notification to affected email addresses about auth detail changes.
+
+ Per ASVS 6.3.7, users must be notified after updates to authentication
+ details such as email address modifications.
+
+ Args:
+ pid: Person identifier
+ change_type: Type of change that occurred
+ old_value: Previous value of the changed field
+ new_value: New value of the changed field
+ notify_emails: List of email addresses to notify (typically both old and new)
+ """
+ for email in notify_emails:
+ _LOGGER.info(
+ f'Sending {change_type.value} notification to {email} '
+ f'for Person[P:{pid}]'
+ )
+ # Implement actual email sending here
+ # Must include: what changed, when, and how to report if unauthorized
+ # Template should provide clear action items for users
+```
+
+**Integration Example:**
+
+```python
+# v3/server/pages.py - Future POST handler example
+@APP.post('/profile/update')
+@asfquart.auth.require
+async def update_profile():
+ from steve.notifications import notify_auth_detail_change, NotificationType
+
+ # ... update logic ...
+
+ if email_changed:
+ await notify_auth_detail_change(
+ pid=user_pid,
+ change_type=NotificationType.EMAIL_CHANGED,
+ old_value=old_email,
+ new_value=new_email,
+ notify_emails=[old_email, new_email] # Notify BOTH addresses
+ )
+```
+
+---
+
+## Positive Security Patterns
+
+| Pattern | Location | Description | Security Benefit |
+|---------|----------|-------------|------------------|
+| Salt protection | `persondb.py:39` | Comment "NEVER return person.salt" | Shows security awareness; prevents password salt exposure |
+| Authentication delegation | `pages.py` (asfquart.auth) | Auth delegated to ASF OAuth | Reduces credential management attack surface |
+| Session-based identity | `pages.py:basic_info()` | User identity from authenticated session | Prevents identity tampering via user input |
+| Election operation logging | `pages.py` (multiple) | Election state changes logged with user context | Provides audit trail for election security events |
+
+---
+
+## Architecture Observations
+
+### 1. Delegated Authentication Model
+
+**Authentication is delegated to ASF OAuth** — The application does not manage credentials directly, which reduces the scope of ASVS 6.3.7 for credential resets. However, the email address stored in `persondb` IS used for election communications and can be silently modified, making it fall under "authentication details" for notification purposes.
+
+### 2. Missing Notification Infrastructure
+
+**No email/notification infrastructure exists** — There is no email sending module, no notification queue, and no message templates for security alerts. The `get_voters_for_email()` method in `election.py` suggests email-based communication is planned or in use, but there's no general notification capability for security events.
+
+### 3. CLI Tool Access Pattern
+
+**CLI tools operate without notification** — Direct database access via CLI tools is intentional for administrative purposes. However, the lack of logging in `add_person` means even administrative actions lack an audit trail, which is a gap for security monitoring.
+
+### 4. Profile Management Evolution
+
+**Profile pages exist but are incomplete** — The `/profile` and `/settings` routes indicate planned user-facing profile management. The current GET-only implementation should be extended with notification infrastructure before POST handlers are added.
+
+---
+
+## Recommendations Summary
+
+### Immediate Actions (Priority 1)
+
+| # | Recommendation | Effort | Impact | Timeline |
+|---|----------------|--------|--------|----------|
+| 1 | **Add logging to `PersonDB.add_person()`** to record all person detail changes with before/after values | Low | Provides audit trail for ASVS 6.3.7 compliance | 1-2 days |
+| 2 | **Add change detection to `add_person()`** — compare old vs new values before upsert to enable targeted notifications | Low | Enables efficient notification (only when details actually change) | 1 day |
+
+### Short-term Actions (Priority 2)
+
+| # | Recommendation | Effort | Impact | Timeline |
+|---|----------------|--------|--------|----------|
+| 3 | **Implement email notification service** for security-relevant changes | Medium | Required for ASVS 6.3.7 Level 3 compliance | 1 week |
+| 4 | **Notify both old and new email addresses** when email is changed | Medium | Prevents silent email takeover — old address alerts legitimate user | 2-3 days |
+
+### Long-term Actions (Priority 3)
+
+| # | Recommendation | Effort | Impact | Timeline |
+|---|----------------|--------|--------|----------|
+| 5 | **When implementing `/profile` and `/settings` POST handlers**, integrate notification service from the start | Medium | Ensures future profile editing complies with ASVS 6.3.7 | Ongoing |
+| 6 | **Create notification message templates** for common authentication detail changes with clear user action items | Medium | Provides consistent, professional security communications | 1 week |
+
+### Implementation Priority Matrix
+
+```
+High Impact │ 3. Notification │ 1. Add logging
+ │ service │ 2. Change detection
+ │ │
+ │ 6. Templates │ 4. Dual email notify
+Low Impact │ │ 5. Profile POST integration
+ └────────────────────┴─────────────────────
+ High Effort Low Effort
+```
+
+---
+
+## Appendix: Files Analyzed
+
+<details>
+<summary><strong>Click to expand full file list (3 files analyzed)</strong></summary>
+
+### High Relevance (Relevance: 3)
+
+1. **`v3/steve/persondb.py`** — Person data management
+ - Contains `add_person()` method that performs upserts without notification
+ - Manages email addresses used for election communications
+ - No audit logging for person detail modifications
+
+2. **`v3/server/pages.py`** — User interface endpoints
+ - Contains `/profile` and `/settings` routes (GET-only)
+ - No notification framework for future profile updates
+ - Uses `basic_info()` to retrieve session user data
+
+### Medium Relevance (Relevance: 2)
+
+3. **`v3/steve/election.py`** — Election management
+ - Contains `get_voters_for_email()` demonstrating email usage
+ - Does not modify authentication details directly
+ - Shows email is used for election-related communications
+
+</details>
+
+---
+
+## Compliance Statement
+
+**ASVS 6.3.7 Compliance Status: ❌ NON-COMPLIANT**
+
+This application does not meet ASVS 6.3.7 (Level 3) requirements. Users are not notified when authentication details (email addresses, names) are modified. Implementation of the recommendations in this report is required to achieve compliance.
+
+**Audit Completed:** Apr 22, 2026
+**Report Version:** 1.0
\ 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