(tooling-agents) branch main updated: ASVS audit: 3.4.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]

[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 b1f3733  ASVS audit: 3.4.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
b1f3733 is described below

commit b1f37331ba7ff6b4d0278184fb265637147ddf61
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:55:37 2026 +0200

    ASVS audit: 3.4.2.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
---
 ASVS/reports/steve/v3/d0aa7e9/all/3.4.2.md | 158 +++++++++++++++++++++++++++++
 1 file changed, 158 insertions(+)

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/3.4.2.md b/ASVS/reports/steve/v3/d0aa7e9/all/3.4.2.md
new file mode 100644
index 0000000..3e01437
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/3.4.2.md
@@ -0,0 +1,158 @@
+# Security Audit Report: ASVS 3.4.2
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 3.4.2 |
+| **Files Analyzed** | 11 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-3.4.2: CORS Access-Control-Allow-Origin Header
+
+### Findings for 3.4.2
+
+#### [LOW]
+**Finding ID**: ASVS-342-LOW-001
+
+**Title**: No explicit CORS policy documentation or configuration
+
+**File**: `v3/server/main.py` and `v3/server/pages.py`
+
+**Analysis**: The application does not set any CORS headers (`Access-Control-Allow-Origin`, `Access-Control-Allow-Credentials`, etc.) anywhere in the codebase. This means the browser's default Same-Origin Policy (SOP) applies, which blocks cross-origin requests from reading responses.
+
+**Assessment**: For a voting system that:
+- Serves HTML pages (not a public API)
+- Has no documented cross-origin consumption requirements
+- Uses session-based authentication
+
+The absence of CORS headers is actually the **correct and secure default**. The SOP blocks cross-origin JavaScript from reading responses, which protects sensitive election data.
+
+**However**: The `saveDate()` JavaScript function in `manage.ezt` uses `fetch()` with JSON:
+```javascript
+const resp = await fetch(`/do-set-${field}/[eid]`, {
+    method: 'POST',
+    headers: {
+        'Content-Type': 'application/json',
+        'X-CSRFToken': csrfToken,
+    },
+    body: JSON.stringify({ date: value }),
+});
+```
+
+The `Content-Type: application/json` header makes this a "non-simple" request that would trigger a CORS preflight if made cross-origin. Without an `Access-Control-Allow-Origin` header in responses, such cross-origin requests would fail — which is the desired behavior.
+
+**Potential concern**: If a reverse proxy or CDN in front of this application adds CORS headers (e.g., `Access-Control-Allow-Origin: *`), sensitive election data (voter lists, election metadata) could be leaked cross-origin. The application should explicitly deny CORS or set restrictive headers as defense-in-depth.
+
+**Remediation** (defense-in-depth):
+```python
+@APP.after_request
+async def set_cors_headers(response):
+    # Explicitly set restrictive CORS - no cross-origin access allowed
+    # This prevents misconfigured reverse proxies from weakening security
+    response.headers['Access-Control-Allow-Origin'] = 'null'
+    return response
+```
+
+### Security Controls Inventory for 3.4.2
+
+| Control | Location | Status |
+|---------|----------|--------|
+| CORS Access-Control-Allow-Origin | Not set (SOP default) | **ACCEPTABLE** (implicit deny) |
+| CORS middleware/configuration | Not found | N/A (not needed for same-origin app) |
+| Cross-origin API endpoints | None identified | N/A |
+
+### Positive Patterns for 3.4.2
+
+- No `Access-Control-Allow-Origin: *` headers anywhere — sensitive data (elections, voters, votes) is protected by SOP
+- The application is designed as a same-origin web application, not a cross-origin API
+- JSON API endpoints (`/do-set-open_at`, `/do-set-close_at`) use `Content-Type: application/json` which triggers CORS preflight, adding an implicit protection layer against cross-origin abuse
+- Static resources (`/static/`) are non-sensitive and would be safe even with permissive CORS
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Session Management Framework Opacity**: The `asfquart` framework handles session cookies, but its configuration is not visible in the audited code. Critical security attributes (SameSite, HttpOnly, Secure, cookie name) are delegated to the framework with no explicit override. This creates an audit gap — the security posture depends on undocumented framework defaults.
+
+2. **No Security Header Middleware**: The application lacks any `after_request` handler or middleware for setting security headers. This means HSTS, CSP, X-Content-Type-Options, X-Frame-Options, and other security headers are all absent from responses.
+
+3. **CSRF Defense Completely Absent**: The combination of:
+   - Placeholder CSRF token (`'placeholder'`)
+   - No SameSite cookie attribute (verified)
+   - State-changing GET endpoints (`/do-open`, `/do-close`)
+   
+   Creates a complete absence of CSRF protection for the voting system. This is the most critical cross-cutting concern.
+
+4. **Defense-in-Depth Gap**: The application relies solely on authentication (`@asfquart.auth.require`) for security. There are no layered defenses (CSRF, origin checking, SameSite cookies, authorization checks). If any single layer is bypassed, there is no fallback.
+
+5. **Acknowledged Technical Debt**: The `TODO.md` and inline `### check authz` comments indicate the development team is aware of security gaps but has not yet addressed them. The code appears to be in active development with security controls planned but not implemented.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Before Any Production Deployment)
+
+1. **Add Security Headers Middleware** (addresses ASVS 3.4.1):
+```python
+@APP.after_request
+async def security_headers(response):
+    response.headers['Strict-Transport-Security'] = 'max-age=31536000; includeSubDomains'
+    response.headers['X-Content-Type-Options'] = 'nosniff'
+    response.headers['X-Frame-Options'] = 'DENY'
+    return response
+```
+
+2. **Configure Session Cookie Securely** (addresses ASVS 3.3.2, 3.3.3, 3.3.4):
+```python
+app.config.update(
+    SESSION_COOKIE_NAME='__Host-steve_session',
+    SESSION_COOKIE_HTTPONLY=True,
+    SESSION_COOKIE_SECURE=True,
+    SESSION_COOKIE_SAMESITE='Strict',
+    SESSION_COOKIE_PATH='/',
+)
+```
+
+3. **Convert State-Changing GET Endpoints to POST** (addresses ASVS 3.3.2):
+   - `/do-open/<eid>` → POST with CSRF token
+   - `/do-close/<eid>` → POST with CSRF token
+
+### Short-term (Within Next Sprint)
+
+4. **Implement Real CSRF Protection** (supports ASVS 3.3.2):
+   - Generate cryptographically random tokens per session
+   - Validate tokens on all state-changing endpoints
+   - Combine with `SameSite=Strict` for defense-in-depth
+
+5. **Add Cookie Size Monitoring** (addresses ASVS 3.3.5):
+   - Log warnings if session cookie approaches 4096 bytes
+   - Consider server-side session storage if flash messages grow
+
+### Long-term (Architecture)
+
+6. **Audit asfquart Framework**: Review the `asfquart` framework source code to verify default cookie attributes, as the application delegates all cookie security to this dependency.
+
+7. **Implement Authorization Layer**: Address the `### check authz` placeholders throughout the codebase to ensure election owners/authorized groups are properly validated, complementing the cookie security controls.
+
+8. **Security Testing**: Add integration tests that verify response headers include HSTS, cookie attributes include SameSite/HttpOnly/Secure, and no CORS headers leak on sensitive endpoints.
+        
\ 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