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

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

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

diff --git a/ASVS/reports/steve/v3/d0aa7e9/all/2.1.2.md b/ASVS/reports/steve/v3/d0aa7e9/all/2.1.2.md
new file mode 100644
index 0000000..dc3c784
--- /dev/null
+++ b/ASVS/reports/steve/v3/d0aa7e9/all/2.1.2.md
@@ -0,0 +1,165 @@
+# Security Audit Report: ASVS 2.1.2
+
+## Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **Repository** | apache/steve/v3 |
+| **Audit Date** | May 05, 2026 |
+| **Auditor** | Tooling Agents (bundled-pass mode) |
+| **ASVS Requirement** | ASVS 2.1.2 |
+| **Files Analyzed** | 10 relevant / 49 total |
+| **Files Skipped** | 12 |
+
+**Requirement description:** Verify that the application's documentation defines how to validate the logical and contextual consistency of combined data items, such as checking that suburb and ZIP code match.
+
+### Findings Overview
+
+| Severity | Count |
+|----------|-------|
+| 🔴 Critical | 0 |
+| 🟠 High | 0 |
+| 🟡 Medium | 2 |
+| 🟢 Low | 0 |
+
+---
+
+## ASVS-2.1.2: Validation and Business Logic Documentation - Contextual Consistency
+
+### Findings for 2.1.2
+
+### [MEDIUM]
+**Finding ID: ASVS-212-MED-001**
+**Title: No documentation of temporal consistency rules for election dates**
+
+**File:** `v3/docs/schema.md`, `v3/server/pages.py`
+
+The documentation does not define rules for validating the logical consistency between `open_at` and `close_at` fields:
+
+```markdown
+# From schema.md:
+  - `open_at` (INTEGER): seconds since epoch
+  - `close_at` (INTEGER): seconds since epoch
+
+# Missing documentation:
+# - Must close_at > open_at?
+# - Can open_at be in the past when setting?
+# - Can close_at be before current time?
+# - What happens if open_at is set after close_at?
+```
+
+The code (`_set_election_date` in pages.py) sets each date independently without any documented cross-field consistency rule:
+
+```python
+async def _set_election_date(election, field):
+    # ...
+    if field == 'open_at':
+        election.set_open_at(dt)
+    elif field == 'close_at':
+        election.set_close_at(dt)
+    # No cross-field consistency check documented or implemented
+```
+
+**Impact:** Without documented consistency rules, dates can be set in illogical combinations (close before open), potentially confusing election administrators and voters.
+
+**Remediation:** Document the expected temporal relationships:
+```markdown
+## Date Consistency Rules
+- `close_at` must be after `open_at` if both are set
+- `open_at` should be in the future when the election is editable
+- Neither date can be modified once the election is closed (enforced by trigger)
+```
+
+---
+
+### [MEDIUM]
+**Finding ID: ASVS-212-MED-002**
+**Title: No documentation of election state consistency with voter/issue operations**
+
+**File:** `v3/docs/schema.md`
+
+While the code enforces state-based restrictions (e.g., can only add issues when editable, can only vote when open), these rules are not documented in the business logic documentation:
+
+```markdown
+# Missing from documentation:
+# - Adding voters is only valid when election.salt IS NULL (editable state)
+# - Adding issues is only valid when election.salt IS NULL
+# - Voting is only valid when election.salt IS NOT NULL AND closed != 1
+# - Tallying is only valid when closed = 1
+# - Issue IID must belong to the election's EID when voting
+# - Voter PID must have a mayvote entry for the issue IID
+```
+
+**Impact:** Without documented consistency rules, it's unclear what invariants the system maintains, making it harder to verify completeness of implementation.
+
+**Remediation:** Add a "State Transition Rules" section documenting which operations are valid in which states and what cross-entity consistency is required.
+
+---
+
+### Security Controls Inventory for 2.1.2
+
+| Control | Location | Coverage Status |
+|---------|----------|-----------------|
+| Election state checks | `election.py` (assert statements) | Implemented but not documented |
+| Foreign key constraints | `schema.sql` (FOREIGN KEY declarations) | Enforced at DB layer |
+| Trigger preventing date changes when closed | `schema.sql` (prevent_open_close_update trigger) | Enforced at DB layer, partially documented |
+| Voter eligibility check (mayvote) | `election.py` line 237 | Implemented but not documented as a rule |
+
+### Positive Patterns for 2.1.2
+
+- **Database trigger for closed election protection:** The `prevent_open_close_update` trigger in `schema.sql` enforces that `open_at` and `close_at` cannot be modified once an election is closed.
+- **Foreign key relationships:** The schema enforces referential integrity between person→election (owner), issue→election, mayvote→person, mayvote→issue.
+- **State-based assertions in code:** `election.py` uses assertions to enforce that operations are only performed in the correct election state.
+
+---
+
+
+
+## Cross-cutting Architecture Observations
+
+1. **Documentation vs. Implementation Gap:** The application has solid database-level documentation (`schema.md`) describing data types and constraints, but lacks a separate input validation specification document. The database schema enforces internal ID formats but not user-input content rules.
+
+2. **Defense-in-Depth Pattern:** The architecture employs multiple layers — database CHECK constraints, foreign keys, application-level state assertions, and authentication decorators. However, the input validation layer (between user input and business logic) is largely absent.
+
+3. **Type A Gaps Dominate:** Most vulnerabilities are "entry point with no control" rather than controls that exist but aren't applied. This suggests input validation was deferred during development (evidenced by multiple TODO/`###` comments).
+
+4. **Asymmetric Validation:** The CLI tool (`create-election.py`) has more validation (STV kv fields, seat count, PID existence) than the web endpoints for equivalent operations. This creates inconsistent security posture between entry points.
+
+5. **State Machine is Well-Implemented:** The election lifecycle (editable → open → closed) is consistently enforced via assertions in `election.py`. This is a strong positive architectural pattern for business logic.
+
+6. **Cryptographic Layer is Solid:** Vote encryption, token generation, and anti-tamper detection are well-structured and correctly separate concerns from the input validation layer.
+
+7. **GET for State Changes:** Using GET requests for irreversible operations (`do-open`, `do-close`) violates REST conventions and makes CSRF prevention more difficult.
+
+## Cross-cutting Recommendations
+
+### Immediate (Critical/High Priority)
+
+1. **Implement votestring validation** in `Election.add_vote()` — this is the core function of the application and currently accepts arbitrary input. Create `validate_vote()` methods in each vtype module.
+
+2. **Convert state-changing GET endpoints to POST** (`/do-open/<eid>`, `/do-close/<eid>`) and implement CSRF token generation and validation. Replace the placeholder token.
+
+3. **Add server-side required field validation** for all form-submitted text fields (title, description) in `do_create_endpoint`, `do_add_issue_endpoint`, and `do_edit_issue_endpoint`.
+
+### Short-term (Medium Priority)
+
+4. **Add cross-field date validation** ensuring `close_at > open_at` when both are set, and consider restricting past dates.
+
+5. **Implement explicit mayvote NULL check** in `add_vote()` to provide clear error handling rather than relying on AttributeError.
+
+6. **Add length limits** on text input fields (title: 200 chars, description: 10,000 chars) both in validation code and as database CHECK constraints.
+
+7. **Create an input validation specification document** covering all user-input fields, their formats, constraints, and cross-field rules.
+
+8. **Validate `docname`** explicitly with an allowlist pattern, even though `send_from_directory` provides framework protection.
+
+### Long-term (Architectural)
+
+9. **Implement authorization (authz) checks** — currently all `### check authz` comments indicate no ownership/permission validation beyond basic authentication.
+
+10. **Create a centralized input validation module** that can be reused across endpoints, rather than inline validation in each handler.
+
+11. **Add per-user and global rate limits** for election creation, issue management, and vote submission to prevent abuse.
+
+12. **Document all business logic rules** in a dedicated specification, including state transitions, temporal constraints, limits, and cross-entity consistency rules.
+        
\ 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