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

commit 37ba0c465d578fed03e168bafc28d55d023366d8
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 14:00:42 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/1.3.7.md b/ASVS/reports/steve/v3/d0aa7e9/all/1.3.7.md
new file mode 100644
index 0000000..68abf31
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/1.3.7.md
@@ -0,0 +1,114 @@
+# Security Audit Report: ASVS 1.3.7
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 1.3.7 |
+| **Files Analyzed** | 5 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 1 |
+
+---
+
+## ASVS-1.3.7: Template Injection Protection
+
+### Findings for 1.3.7
+
+#### LOW
+**Finding ID:** ASVS-137-LOW-001
+**Location:** `v3/server/pages.py`, function `rewrite_description`, line 49
+**Description:** While EZT templates are loaded from static files (not user-controlled), user-supplied content is formatted into HTML strings that are passed as template data. If EZT were to re-interpret template directives within variable values, this could enable server-side template injection. Based on EZT's documented behavior, variable values are output as-is without re-parsing, making this low risk.
+
+```python
+def rewrite_description(issue):
+    desc = issue.description
+    # ...
+    issue.description = f'<pre>{desc}</pre>'
+```
+
+If a description contains EZT syntax like `[include "/etc/passwd"]`, it would be output literally (not interpreted) because EZT does not re-process data values as template code. However, this assumption should be verified.
+
+**Data flow:** User input → stored in database → retrieved and set as template variable → EZT renders variable → output as literal text (NOT re-parsed).
+
+**Impact:** Low. EZT is designed to NOT re-interpret data values. However, if this assumption is incorrect for the specific version in use, it could lead to arbitrary file read or code execution.
+
+**Remediation:** Verify EZT behavior explicitly. As defense-in-depth:
+```python
+# Validate that descriptions don't contain EZT template directives
+import re
+EZT_PATTERN = re.compile(r'\[(?:include|if|for|is|define|format)')
+if EZT_PATTERN.search(description):
+    # Log and strip or reject
+    description = EZT_PATTERN.sub('', description)
+```
+
+### Security Controls Inventory for 1.3.7
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Static template loading | `APP.load_template()`, `@APP.use_template()` | All templates loaded from filesystem constants |
+| Template paths not user-controlled | All `TEMPLATES / '...'` references | **Correctly implemented** |
+| EZT variable output (no re-parsing) | EZT engine behavior | Assumed but not explicitly verified |
+
+### Positive Patterns for 1.3.7
+
+- All template paths are constructed from static constants (`TEMPLATES / 'manage.ezt'`, etc.) — no user input influences template selection.
+- Templates are pre-loaded via `APP.load_template()` at module load time or via decorators, not dynamically constructed.
+- The EZT engine uses `[variable]` syntax for data substitution which is distinct from template loading/compilation — data values are not re-parsed as template code.
+- No string concatenation or f-string interpolation is used to build template source code.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Output Encoding Inconsistency (Type B Gap Pattern):** The EZT templating system provides the `[format "js,html"]` encoding directive, and developers correctly apply it in JavaScript contexts. However, the same data (issue titles, descriptions, election titles) is rendered WITHOUT encoding in HTML body contexts. This represents a systematic Type B gap where the control exists but is not consistently applied.
+
+2. **No Input Sanitization Layer:** The application has no centralized input sanitization for user-supplied content. Issue titles, descriptions, and election titles flow directly from form input to database storage to template rendering without any intermediate sanitization step.
+
+3. **Defense-in-Depth Absence:** The application relies solely on authentication (`@asfquart.auth.require`) for security. There is no:
+   - Content Security Policy (CSP) headers
+   - Input sanitization middleware
+   - Output encoding applied by default
+   - CSRF token validation (acknowledged as placeholder)
+
+4. **Privileged User Attack Surface:** While all endpoints require authentication (committer or PMC member), the stored XSS vulnerabilities mean any compromised or malicious insider can attack all other users of the system. In an election/voting context, this is particularly severe as it could undermine election integrity.
+
+5. **Template Engine Choice:** EZT does not auto-escape by default (unlike Jinja2's `autoescape=True`). This architectural choice places the burden on developers to manually encode every output point, which has demonstrably led to gaps.
+
+---
+
+## Cross-cutting Recommendations
+
+### Immediate (address before next deployment)
+1. **Apply `[format "html"]` to ALL user-derived template variables** in HTML contexts — at minimum: `[issues.title]`, `[issues.description]`, `[e_title]`, `[flashes.message]`.
+2. **HTML-escape content in `rewrite_description()`** before wrapping in `<pre>` tags and before constructing `<a>` attributes.
+3. **Sanitize flash messages** — escape `form.title` and similar user input before interpolating into flash strings.
+
+### Short-term (within next sprint)
+4. **Implement a Content Security Policy** header (`script-src 'self'`) to mitigate XSS impact even if encoding is missed.
+5. **Add `X-Content-Type-Options: nosniff`** to document responses from `serve_doc()` to prevent MIME-type sniffing of uploaded files.
+6. **Restrict served document types** in `serve_doc()` to a whitelist of safe extensions (PDF, TXT, PNG, etc.), blocking SVG and HTML.
+7. **Implement input sanitization** for issue descriptions — either use a library like `bleach` to allow safe HTML subset, or store as plain text and render encoded.
+
+### Long-term (architectural improvements)
+8. **Migrate from EZT to a template engine with auto-escaping** (e.g., Jinja2 with `autoescape=True`). This eliminates the class of bugs where developers forget to encode.
+9. **Implement a centralized input validation/sanitization layer** as middleware that processes all form submissions before they reach handlers.
+10. **Implement real CSRF protection** — the placeholder token provides zero security and creates false confidence (Type B gap at the architecture level).
+11. **Add security-focused integration tests** that attempt XSS payloads through each input field and verify they are neutralized in rendered output.
+        
\ 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