(tooling-agents) branch main updated: ASVS audit: 1.2.10.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 9037682  ASVS audit: 1.2.10.md (redacted) [source: apache/steve/v3 @ d0aa7e9]
9037682 is described below

commit 903768221ca864cbfece7f468dcf31c8ffb09746
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:49:56 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/1.2.10.md b/ASVS/reports/steve/v3/d0aa7e9/all/1.2.10.md
new file mode 100644
index 0000000..078f6b7
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/1.2.10.md
@@ -0,0 +1,110 @@
+# Security Audit Report: ASVS 1.2.10
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 1.2.10 |
+| **Files Analyzed** | 8 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application is protected against CSV and Formula Injection. The application must follow the escaping rules defined in RFC 4180 sections 2.6 and 2.7 when exporting CSV content. Additionally, when exporting to CSV or other spreadsheet formats (such as XLS, XLSX, or ODF), special…
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-1.2.10: Injection Prevention - CSV and Formula Injection
+
+### Findings for 1.2.10
+
+No findings detected.
+
+### Security Controls Inventory for 1.2.10
+
+No applicable controls in this scope. The audited codebase does not contain any CSV, XLS, XLSX, or ODF export functionality. The `tally_issue` method returns data programmatically but does not export to spreadsheet formats. The `mail-voters.py` script sends emails but does not generate CSV content.
+
+### Positive Patterns for 1.2.10
+
+1. **No CSV export endpoints exist:** The application does not expose any functionality that generates downloadable spreadsheet files, eliminating this attack surface entirely in the current codebase.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+### 1. Inconsistent Encoding Strategy (Type B Pattern)
+The most critical cross-cutting observation is the **inconsistent application of encoding controls**:
+- `manage.ezt` and `manage-stv.ezt` correctly use `[format "js,html"]` for JavaScript-in-HTML contexts
+- `vote-on.ezt` (the voter-facing page) does NOT use any format directives for the same type of data
+
+This is a Type B gap (control exists but not applied) and represents false confidence — developers may believe the voter page is safe because they applied controls elsewhere.
+
+### 2. EZT Template Engine Default Behavior
+The application relies on an EZT template engine that does NOT HTML-encode output by default. This is evidenced by:
+- The `rewrite_description` function constructing raw HTML that must pass through without escaping
+- The selective use of `[format]` directives only in specific contexts
+- No visible `base_format` configuration
+
+This architectural choice means every template variable is a potential XSS vector unless explicitly wrapped in a `[format]` directive.
+
+### 3. Data Storage in Original Form (Positive)
+The application correctly stores data in its original form in the database — no pre-encoding. This prevents double-encoding issues but places the full burden of output encoding on the template layer, which currently has gaps.
+
+### 4. Mixed HTML Construction Patterns
+HTML is constructed in multiple locations:
+- Server-side in Python (`rewrite_description`)
+- Server-side in EZT templates (all templates)
+- Client-side in JavaScript (`makeItem()`)
+
+Each location needs its own encoding strategy, but only the client-side JavaScript consistently applies it.
+
+### 5. State-Changing GET Requests
+The `/do-open/<eid>` and `/do-close/<eid>` endpoints use GET methods for state-changing operations. Combined with the placeholder CSRF tokens, these are trivially exploitable via CSRF (e.g., `<img src="/do-open/KNOWN_EID">`).
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical — address before next deployment)
+
+1. **Add `[format "js"]` encoding to ALL JavaScript-embedded values in `vote-on.ezt`** (ASVS-123-CRIT-001, ASVS-121-CRIT-001). This is the highest-priority fix as it affects the voter-facing ballot page and could allow manipulation of election results.
+
+2. **Fix `rewrite_description` to HTML-encode description content** before wrapping in `<pre>` tags (ASVS-112-HIGH-001). Apply `html.escape()` to the description text and `urllib.parse.quote()` to filenames in constructed URLs.
+
+### Short-term (within current sprint)
+
+3. **Establish a template encoding standard:** Either:
+   - Configure EZT with `base_format = FORMAT_HTML` and use `[format "raw"]` only where intentional raw HTML is needed, OR
+   - Audit ALL templates and add explicit `[format "html"]` to every user-derived variable in HTML contexts
+
+4. **Add `[format "html"]` to all unencoded template outputs** including:
+   - `election.title`, `election.owner_name`, `election.authz` in all templates
+   - `issues.title`, `issues.description` in manage templates
+   - Flash message content in `flashes.ezt`
+
+5. **Fix flash messages** to either encode at creation or ensure template-level encoding (ASVS-112-MED-001).
+
+6. **Add explicit validation to `serve_doc`** for the `docname` parameter — restrict to alphanumeric plus safe punctuation (ASVS-111-MED-001).
+
+### Long-term (architectural)
+
+7. **Consider migrating to JSON embedding pattern** for complex JavaScript data: serialize server-side with `json.dumps()` and parse client-side with `JSON.parse()` from a `<script type="application/json">` tag. This is inherently safer than template-based JS construction.
+
+8. **Implement a Content Security Policy (CSP)** header to mitigate XSS impact. At minimum, restrict `script-src` to prevent inline script execution, which would require refactoring inline scripts to external files.
+
+9. **Implement real CSRF protection** — the placeholder tokens provide zero security. Use a proper CSRF library that generates per-session tokens and validates them on all state-changing requests.
+
+10. **Convert state-changing GET endpoints** (`/do-open/`, `/do-close/`) to POST methods with CSRF validation.
+        
\ 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