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

commit 0fe67c9f20c59ec39dadc330f0f555a36432ce58
Author: ASF Tooling Team <ro...@apache.org>
AuthorDate: Tue May 5 22:56:38 2026 +0200

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/5.2.1.md b/ASVS/reports/steve/v3/d0aa7e9/all/5.2.1.md
new file mode 100644
index 0000000..b61c2a4
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/5.2.1.md
@@ -0,0 +1,130 @@
+# Security Audit Report: ASVS 5.2.1
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 5.2.1 |
+| **Files Analyzed** | 4 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application will only accept files of a size which it can process without causing a loss of performance or a denial of service attack.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 1 |
+| 🟡 Medium | 0 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-5.2.1: File Size Limits
+
+### Findings for 5.2.1
+
+#### HIGH
+**Finding ID:** ASVS-521-HIGH-001
+**Location:** `v3/server/pages.py` — entire application scope
+
+**Description:** The application serves documents via `/docs/<iid>/<docname>` but has no visible file upload endpoint with size validation. The mechanism by which documents are placed into `DOCSDIR` is not shown in the provided code, meaning there are no observable file size checks that would prevent a denial of service via excessively large files. If files are uploaded through an undocumented mechanism, no size limits are enforced by the shown code.
+
+Additionally, the Quart application does not set `MAX_CONTENT_LENGTH` (or equivalent) to limit request body size globally, which would affect any file upload functionality added in the future.
+
+**Vulnerable code quote:**
+```python
+DOCSDIR = THIS_DIR / 'docs'
+
+# ...
+
+# Serve supporting documents for an issue
+@APP.get('/docs/<iid>/<docname>')
+@asfquart.auth.require
+async def serve_doc(iid, docname):
+    # No size validation anywhere
+    return await quart.send_from_directory(DOCSDIR / iid, docname)
+```
+
+**Data flow:** Unknown upload mechanism → files placed in `DOCSDIR/<iid>/` → no size check → potential storage exhaustion or DoS when serving very large files
+
+**Impact:** Without file size limits, an attacker (or misconfigured admin process) could place arbitrarily large files that exhaust disk space or cause memory/bandwidth exhaustion when served to users.
+
+**Remediation:**
+```python
+# In application configuration
+APP.config['MAX_CONTENT_LENGTH'] = 10 * 1024 * 1024  # 10 MB max upload
+
+# In any file upload handler (if/when implemented)
+async def upload_doc(iid):
+    file = (await quart.request.files).get('document')
+    if not file:
+        quart.abort(400, 'No file provided')
+    
+    # Check file size
+    file.seek(0, 2)  # Seek to end
+    size = file.tell()
+    file.seek(0)  # Reset
+    
+    MAX_FILE_SIZE = 10 * 1024 * 1024  # 10 MB
+    if size > MAX_FILE_SIZE:
+        quart.abort(413, f'File too large. Maximum size is {MAX_FILE_SIZE} bytes')
+    
+    # ... proceed with validated file
+```
+
+### Security Controls Inventory for 5.2.1
+
+| Control | Location | Status |
+|---------|----------|--------|
+| `MAX_CONTENT_LENGTH` configuration | Not present | **MISSING** |
+| Per-file size check | Not present | **MISSING** |
+| File upload handler | Not present in provided code | **MISSING** |
+| Disk quota enforcement | Not present | **MISSING** |
+
+### Positive Patterns for 5.2.1
+
+- No findings of positive patterns for this requirement. The file serving mechanism exists but file size control is entirely absent.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Missing Upload Mechanism:** The application has a clear document serving architecture (`DOCSDIR/<iid>/<docname>`, `serve_doc` endpoint, `rewrite_description` link generation) but no visible upload handler in the provided code. This creates a Type B gap — the authorization control for serving documents exists, but without a corresponding upload handler with security controls, the safety of served files cannot be guaranteed.
+
+2. **Acknowledged Technical Debt:** The comment `### verify the propriety of DOCNAME.` in `serve_doc` (line 571) indicates the development team is aware of the gap but has not yet addressed it. This is a conscious risk acceptance without documented mitigation.
+
+3. **Framework-Level Protections:** The application relies on `quart.send_from_directory` for path safety, which is a reasonable baseline but insufficient for ASVS L2/L3 compliance. The framework prevents directory traversal via path manipulation but does not address file content safety, symlinks, or archive bombs.
+
+4. **Schema Has No File Metadata:** The `v3/schema.sql` database schema has no table for tracking uploaded files, their sizes, types, or ownership. This makes it architecturally impossible to enforce per-user quotas, file type policies, or audit file uploads without schema changes.
+
+5. **Defense-in-Depth Absent for Files:** The application has multiple layers for election security (cryptographic salts, anti-tamper keys, encrypted votes) but zero layers for file security. This asymmetry suggests file handling was not part of the initial security design.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical)
+1. **Add file extension allowlist to `serve_doc`** — Implement a whitelist of permitted extensions (`.pdf`, `.txt`, `.png`) and reject requests for unlisted types. This is the minimum viable control for the existing serving endpoint.
+2. **Add `X-Content-Type-Options: nosniff` and `Content-Disposition: attachment`** headers to all file serve responses to prevent content sniffing and force download behavior.
+3. **Add symlink check** — Before serving any file, verify `not filepath.is_symlink()`.
+
+### Short-term (High)
+4. **Implement a documented file upload handler** with:
+   - `MAX_CONTENT_LENGTH` configured in Quart
+   - Extension validation against an allowlist
+   - Magic bytes verification using `python-magic`
+   - Maximum file size per upload
+5. **Create file handling documentation** that satisfies ASVS 5.1.1 — define permitted types, extensions, sizes, and malicious file handling behavior.
+6. **Add a `user_files` tracking table** to the database schema to enable quota enforcement.
+
+### Long-term (Medium)
+7. **Implement compressed file validation** — detect archives, check uncompressed size and file count, reject symlinks.
+8. **Implement per-user storage quotas** with configurable limits and enforcement at upload time.
+9. **Add virus/malware scanning** integration (e.g., ClamAV) for uploaded documents.
+10. **Implement image rewriting** for any accepted image files to strip metadata and neutralize polyglot attacks.
+        
\ 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