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

commit 837d89cb7c8eb81e4f32eb3f95f55ccb0642bae7
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:06:58 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/3.5.6.md b/ASVS/reports/steve/v3/d0aa7e9/all/3.5.6.md
new file mode 100644
index 0000000..631ad90
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/3.5.6.md
@@ -0,0 +1,96 @@
+# Security Audit Report: ASVS 3.5.6
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 3.5.6 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-3.5.6: Browser Origin Separation - JSONP
+
+### Findings for 3.5.6
+
+No findings detected.
+
+**Analysis:** A review of all code reveals no JSONP functionality:
+- No `callback` query parameter handling in any endpoint
+- No dynamic script tag generation for data loading
+- No response wrapping in function calls
+- API endpoints return either HTML (template rendering) or empty 204 responses
+- The `queries.yaml` file shows only standard SQL queries with no callback mechanisms
+- JavaScript code uses `fetch()` API for AJAX calls (not JSONP script injection)
+
+### Security Controls Inventory for 3.5.6
+
+| Control | Location | Status |
+|---------|----------|--------|
+| JSONP endpoint prevention | All endpoints in `pages.py` | ✅ No JSONP endpoints exist |
+| Data API response format | `_set_election_date` returns `('', 204)` | ✅ Returns empty body, not callable JS |
+
+### Positive Patterns for 3.5.6
+
+- All data fetching uses modern `fetch()` API with proper Content-Type headers
+- No endpoints accept or honor a `callback` parameter
+- Server responses are either full HTML pages (via template rendering) or empty 204 responses
+- No dynamic JavaScript generation based on user input in API responses
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **CSRF Protection is Entirely Absent Despite Apparent Intent:** The codebase shows clear architectural intent to implement CSRF protection (token fields in templates, header passing in fetch calls, TODO items acknowledging it), but the actual enforcement is completely missing. This creates a dangerous false sense of security — developers and reviewers may believe protection exists because they see the tokens in templates.
+
+2. **GET-Based State Changes Compound the CSRF Problem:** The `/do-open/<eid>` and `/do-close/<eid>` endpoints using GET method means that even implementing CSRF tokens for POST requests would leave these critical operations unprotected. These must be converted to POST before any CSRF solution is effective.
+
+3. **Authorization Model is Incomplete:** Multiple `### check authz` placeholders indicate that ownership verification (e.g., "does this user own this election?") is not enforced. Any authenticated committer can manage any election. While this is beyond the scope of ASVS 3.5.x, it amplifies the impact of CSRF — an attacker doesn't need to target the election owner specifically.
+
+4. **Template Security is Well-Implemented:** The use of `[format "js,html"]` in EZT templates for user-supplied data injected into JavaScript contexts shows awareness of XSS prevention, which is relevant because XSS can bypass CSRF protections.
+
+5. **Client-Server Contract Mismatch:** The client (templates) sends CSRF tokens and custom headers that the server completely ignores. This indicates the frontend was developed with security in mind but the backend implementation was deferred.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical — deploy blockers)
+
+1. **Implement CSRF token validation on all POST endpoints.** Generate a cryptographically random token per session, store it server-side, and validate it on every state-changing request. Use a decorator pattern for consistency.
+
+2. **Convert `/do-open/<eid>` and `/do-close/<eid>` from GET to POST.** These perform irreversible operations and must not be triggerable via simple navigation, image loads, or link prefetch.
+
+3. **Add Origin header validation** as defense-in-depth for all POST endpoints, rejecting requests with an Origin header that doesn't match the application's own origin.
+
+### Short-term (High priority — within sprint)
+
+4. **Enforce Content-Type validation** on form endpoints — reject requests that don't match `application/x-www-form-urlencoded` or `multipart/form-data` as appropriate. For JSON endpoints, reject non-`application/json` requests.
+
+5. **Configure SameSite=Lax (minimum) or SameSite=Strict on session cookies.** This provides browser-level CSRF protection for most scenarios while the token-based approach covers older browsers.
+
+6. **Add Sec-Fetch-Site header checking** as an additional defense layer — reject requests where `Sec-Fetch-Site: cross-site` on sensitive endpoints.
+
+### Long-term (Architecture improvements)
+
+7. **Consider hostname-based separation** for admin and voter functionality to leverage Same-Origin Policy restrictions between functional domains.
+
+8. **Implement a comprehensive security middleware stack** that handles CSRF, CORS, and Content-Type validation in one place rather than requiring per-endpoint implementation.
+
+9. **Add integration tests** that verify CSRF protection by attempting state-changing requests without valid tokens and asserting they fail with 403.
+        
\ 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