akanealw/Charon
1
0
Fork 0
Code Issues Pull Requests Actions 16 Packages Projects Releases Wiki Activity

chore: clean .gitignore cache

Browse Source
This commit is contained in:
GitHub Actions
2026-01-26 19:21:33 +00:00
parent 1b1b3a70b1
commit e5f0fec5db
1483 changed files with 0 additions and 472793 deletions
Download Patch File Download Diff File Expand all files Collapse all files

607
docs/security/VULNERABILITY_ACCEPTANCE.md
View File

@@ -1,607 +0,0 @@
# Vulnerability Acceptance Document - PR #461
This document provides formal acceptance and risk assessment for vulnerabilities identified in PR #461 (DNS Challenge Support).
**PR**: [#461 - DNS Challenge Support](https://github.com/Wikid82/Charon/pull/461)
**Date Accepted**: 2026-01-13
**Reviewed By**: Security Team & Engineering
**Status**: ACCEPTED (No fixes available from Alpine upstream)
**Next Review**: 2026-02-13 (30 days)
---
## Executive Summary
PR #461 supply chain scan identified **9 vulnerabilities** in Alpine Linux 3.23.0 base image packages:
- **8 Medium severity CVEs** (3 busybox-related, 5 curl-related)
- **1 Low severity CVE** (curl)
**Decision**: All vulnerabilities are **ACCEPTED** pending upstream Alpine Security Team patches. No application-level vulnerabilities were found.
**Rationale**:
- All CVEs are Alpine OS package issues, not Charon application code
- No patches available from Alpine upstream as of 2026-01-13
- Low exploitability in containerized deployment environment
- Effective mitigation strategies in place
- Active monitoring for upstream patches
---
## Vulnerability Details
### CVE-2025-60876: busybox utilities (3 packages)
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 7.5 (Estimated)
**CWE**: CWE-122 (Heap-based Buffer Overflow)
#### Affected Components
- **busybox**: 1.37.0-r20 (Alpine APK)
- **busybox-binsh**: 1.37.0-r20 (Alpine APK)
- **ssl_client**: 1.37.0-r20 (Alpine APK)
#### Vulnerability Description
Heap buffer overflow vulnerability in busybox utilities. The vulnerability exists in the parsing logic of certain busybox commands, potentially allowing memory corruption if specific command patterns are used.
**Attack Vector**: Requires local shell access or specific command execution with attacker-controlled arguments.
#### Risk Assessment
**Exploitability**: **LOW**
- Requires local shell access to container
- Charon does not expose shell access to users via application interface
- Container runs with non-root user (caddy:caddy)
- No busybox commands accept user-controlled input through Charon APIs
**Impact**: **LOW-MEDIUM**
- Potential for command execution or privilege escalation if exploited
- Container isolation limits blast radius
- SELinux/AppArmor policies provide defense-in-depth
- No exposed attack surface through Charon application
**Risk Level**: **LOW** (Low exploitability × Medium impact in isolated environment = Low overall risk)
#### Mitigation Strategies
1. **Container Isolation**: Application runs in isolated Docker container with minimal privileges
2. **Non-Root User**: Container process runs as `caddy:caddy`, not root
3. **No Shell Exposure**: Application does not provide shell access or command execution interfaces
4. **Network Segmentation**: Container network isolated from host and other containers
5. **Read-Only Filesystem**: Application binaries and system files mounted read-only where possible
6. **Capabilities Drop**: Container runs with minimal Linux capabilities (`CAP_NET_BIND_SERVICE` only)
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine Security advisories
- **Source**: <https://security.alpinelinux.org/vuln/busybox>
- **Alert Trigger**: Patch release for CVE-2025-60876
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-15079: curl - HTTP/2 Protocol Handling
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 6.5 (Estimated)
**CWE**: CWE-835 (Loop with Unreachable Exit Condition)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Denial of Service vulnerability in curl's HTTP/2 protocol handling. A malicious server can cause infinite loop or resource exhaustion in curl client when processing crafted HTTP/2 responses.
**Attack Vector**: Requires curl to connect to malicious HTTP/2 server.
#### Risk Assessment
**Exploitability**: **LOW**
- curl only used for internal healthcheck scripts in Charon
- All curl invocations use hardcoded, internal URLs (`http://localhost:8080`)
- No user-controlled URLs passed to curl
- No external HTTP/2 connections from curl in production
**Impact**: **LOW**
- Could cause healthcheck script to hang or consume CPU
- Container restart resolves issue
- Monitoring detects unhealthy container state
- Application functionality unaffected (healthchecks are auxiliary)
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **Hardcoded URLs**: All curl invocations use internal, localhost endpoints only
2. **No User Input**: curl commands never accept user-provided URLs or parameters
3. **Timeout Protection**: Healthcheck scripts include timeout values
4. **Monitoring**: Container health status monitored; automatic restart on failure
5. **Limited Usage**: curl only used for healthchecks; application uses Go HTTP client for real work
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-15079
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-14819: curl - TLS Certificate Validation
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 6.8 (Estimated)
**CWE**: CWE-295 (Improper Certificate Validation)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Improper certificate validation in libcurl when using specific TLS configurations. Under certain conditions, curl may not properly validate certificate chains, potentially allowing man-in-the-middle attacks.
**Attack Vector**: Requires network positioning and crafted TLS certificates.
#### Risk Assessment
**Exploitability**: **LOW**
- curl only used for localhost healthcheck (`http://` not `https://`)
- No TLS connections made by curl in Charon deployment
- Internal network environment (container to localhost)
- No external network access from curl invocations
**Impact**: **LOW**
- No sensitive data transmitted via curl
- Healthcheck endpoints are internal status checks only
- Application uses Go's crypto/tls for all real TLS connections
- curl TLS not used in production deployment
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **No TLS Usage**: curl invocations use HTTP, not HTTPS (localhost only)
2. **Internal Network**: curl only connects to localhost (127.0.0.1:8080)
3. **Go HTTP Client**: Application uses Go's standard library for all external HTTPS connections
4. **Network Isolation**: Container network isolated from external networks
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-14819
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-14524: curl - Cookie Handling
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 5.9 (Estimated)
**CWE**: CWE-200 (Exposure of Sensitive Information)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Cookie handling vulnerability in libcurl that may expose cookies to unintended domains under specific redirect scenarios.
**Attack Vector**: Requires malicious server with redirect chains and cookie manipulation.
#### Risk Assessment
**Exploitability**: **LOW**
- curl does not use cookies in Charon deployment
- Healthcheck scripts do not enable cookie handling
- No cookie jar files used
- Internal localhost-only connections
**Impact**: **LOW**
- No cookies used in curl invocations
- Healthcheck endpoints do not set or require cookies
- No sensitive data in curl requests
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **No Cookie Usage**: curl invocations do not use `-c` or `-b` flags (no cookie support)
2. **Internal Endpoints**: curl only connects to localhost healthcheck endpoints
3. **No Redirects**: Healthcheck endpoints do not issue redirects
4. **Stateless Checks**: Healthchecks are simple HTTP GET requests without state
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-14524
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-13034: curl - URL Parsing
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 6.1 (Estimated)
**CWE**: CWE-20 (Improper Input Validation)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
URL parsing vulnerability that may allow URL injection or filter bypass when parsing specially crafted URLs with unusual schemes or malformed components.
**Attack Vector**: Requires curl to process attacker-controlled URLs with malicious formatting.
#### Risk Assessment
**Exploitability**: **LOW**
- All curl URLs are hardcoded in healthcheck scripts
- No user input accepted for URL construction
- Simple localhost URLs only (`http://localhost:8080/api/v1/health`)
- No URL parsing of external or user-provided data
**Impact**: **LOW**
- Hardcoded URLs are validated at build time
- No dynamic URL construction in curl invocations
- Healthcheck script failure triggers container restart (non-critical)
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **Hardcoded URLs**: All curl URLs are string literals in scripts (no variables)
2. **Input Validation**: No external input used in URL construction
3. **Simple URLs**: Only basic HTTP localhost URLs used
4. **Code Review**: Healthcheck scripts reviewed for security
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-13034
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-10966: curl - Cookie Domain Bypass
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 6.5 (Estimated)
**CWE**: CWE-285 (Improper Authorization)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Cookie domain validation bypass allowing cookies to be sent to unintended domains under specific redirect scenarios with domain matching edge cases.
**Attack Vector**: Requires malicious server with crafted Set-Cookie headers and redirect chains.
#### Risk Assessment
**Exploitability**: **LOW**
- curl does not use cookies in Charon deployment
- No cookie jar functionality enabled
- Internal localhost-only connections
- No redirects in healthcheck endpoints
**Impact**: **LOW**
- No cookies stored or transmitted by curl
- Healthcheck scripts are stateless
- No sensitive data in curl requests
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **No Cookie Usage**: curl invocations do not enable cookie handling
2. **Internal Network**: curl only connects to localhost (no external domains)
3. **No Redirects**: Healthcheck endpoints return direct responses
4. **Stateless Design**: Healthchecks do not require session state
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-10966
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-15224: curl - Information Disclosure
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: LOW
**CVSS**: 3.7 (Estimated)
**CWE**: CWE-200 (Exposure of Sensitive Information)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Minor information disclosure vulnerability in curl verbose logging that may expose sensitive HTTP headers or metadata in debug output.
**Attack Vector**: Requires verbose logging enabled and access to curl output/logs.
#### Risk Assessment
**Exploitability**: **LOW**
- curl not run with verbose flags in production
- Healthcheck scripts use minimal output
- No sensitive data in healthcheck requests
- Container logs do not expose curl debug output
**Impact**: **LOW**
- Healthcheck requests contain no sensitive information
- Verbose mode not enabled in production scripts
- Container logs filtered and access-controlled
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **No Verbose Logging**: curl invocations do not use `-v` or `--verbose` flags
2. **Minimal Output**: Healthcheck scripts capture only exit codes
3. **No Sensitive Data**: Healthcheck requests contain only localhost URLs
4. **Log Access Control**: Container logs require authentication to access
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-15224
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-14017: curl - Protocol Downgrade
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-13
**Severity**: MEDIUM
**CVSS**: 6.8 (Estimated)
**CWE**: CWE-757 (Selection of Less-Secure Algorithm During Negotiation)
#### Affected Components
- **curl**: 8.14.1-r2 (Alpine APK)
- **libcurl**: 8.14.1-r2 (implicit dependency)
#### Vulnerability Description
Protocol downgrade vulnerability in curl that may allow downgrade from HTTP/2 to HTTP/1.1 or TLS version downgrade in specific server response scenarios.
**Attack Vector**: Requires man-in-the-middle position or malicious server with protocol negotiation manipulation.
#### Risk Assessment
**Exploitability**: **LOW**
- curl only connects to localhost (no external network path)
- HTTP only (no TLS connections from curl)
- No protocol negotiation in simple healthcheck GET requests
- Internal container network (no MITM possibility)
**Impact**: **LOW**
- Localhost-only connections eliminate MITM attack vector
- No sensitive data transmitted via curl
- Protocol downgrade irrelevant for HTTP localhost connections
**Risk Level**: **LOW** (Low exploitability × Low impact = Low overall risk)
#### Mitigation Strategies
1. **Localhost Only**: curl connects to 127.0.0.1 (no external network path)
2. **HTTP Only**: No TLS connections (protocol downgrade not applicable)
3. **Internal Network**: Container network isolated from external threats
4. **Simple Requests**: Basic HTTP GET requests with no protocol negotiation
#### Monitoring & Remediation Plan
- **Monitoring Frequency**: Daily checks of Alpine and curl security advisories
- **Source**: <https://security.alpinelinux.org/vuln/curl>
- **Alert Trigger**: Patch release for CVE-2025-14017
- **Remediation Action**: Automatic rebuild with updated Alpine base image
- **Review Date**: 2026-02-13 (30 days) or upon patch release, whichever is sooner
---
## Summary Risk Matrix
| CVE ID | Component | Severity | Exploitability | Impact | Overall Risk | Status |
|--------|-----------|----------|----------------|--------|--------------|--------|
| CVE-2025-60876 | busybox (3 pkgs) | MEDIUM | LOW | LOW-MEDIUM | **LOW** | ✅ Accepted |
| CVE-2025-15079 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-14819 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-14524 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-13034 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-10966 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-15224 | curl | LOW | LOW | LOW | **LOW** | ✅ Accepted |
| CVE-2025-14017 | curl | MEDIUM | LOW | LOW | **LOW** | ✅ Accepted |
**Total**: 9 Alpine OS package CVEs
**Application Code Vulnerabilities**: 0 (Clean)
---
## Continuous Monitoring
### Automated Monitoring
1. **GitHub Dependabot**: Monitors Alpine package updates
2. **Renovate Bot**: Automated PR creation for base image updates
3. **Trivy Scanning**: Weekly security scans in CI/CD (Sunday 02:00 UTC)
4. **Supply Chain Verification**: Runs on every PR and release
### Manual Monitoring
1. **Daily Checks**: Alpine Security Team advisories during active incident periods
2. **Weekly Reviews**: Security team reviews Alpine security feed
3. **Monthly Reviews**: Comprehensive review of all accepted risks (1st Monday)
4. **Quarterly Reviews**: Full risk re-assessment and mitigation strategy evaluation
### Alert Triggers
Immediate escalation if:
- Severity upgraded to HIGH or CRITICAL
- Active exploitation detected in the wild
- CISA KEV (Known Exploited Vulnerabilities) listing
- Public proof-of-concept exploit published
- Regulatory/compliance requirement to remediate
---
## Remediation Timeline
### Expected Upstream Fixes
- **busybox (CVE-2025-60876)**: Awaiting Alpine Security Team patch
- **curl (7 CVEs)**: Awaiting Alpine Security Team patches
### Automatic Remediation Process
1. **Detection**: Renovate Bot detects updated Alpine base image
2. **PR Creation**: Automated PR created with base image update
3. **CI Validation**: Full security scan suite runs
4. **Review**: Security team reviews changes
5. **Merge**: Auto-merge if all checks pass
6. **Deploy**: Automatic release with updated base image
**Estimated Time to Remediation**: < 24 hours after upstream patch release
### Manual Escalation Path
If no patches available after review date (2026-02-13):
1. **Risk Re-Assessment**: Evaluate if risk profile has changed
2. **Alternative Base Images**: Consider Debian slim, distroless, or scratch
3. **Workarounds**: Evaluate removing curl/busybox from final image stage
4. **Accept Extended**: Extend acceptance with updated review date
---
## Compliance & Audit
### Regulatory Considerations
- **NIST SP 800-53**: RA-3 (Risk Assessment), RA-5 (Vulnerability Scanning)
- **ISO 27001**: A.12.6.1 (Management of technical vulnerabilities)
- **CIS Controls**: Control 7 (Continuous Vulnerability Management)
- **SOC 2**: CC7.1 (System Operations - Vulnerability Management)
### Audit Trail
This document provides evidence of:
- Vulnerability identification and assessment
- Risk-based decision making
- Mitigation strategies implementation
- Continuous monitoring process
- Defined remediation timeline
### Approval Record
**Reviewed By**: Security Team & Engineering Director
**Approved By**: Engineering Director
**Date**: 2026-01-13
**Next Review**: 2026-02-13 (30 days)
**Approval Rationale**:
All 9 vulnerabilities are Alpine OS base image packages with no upstream patches available. The assessed risk is LOW across all CVEs due to:
1. Effective containerization and isolation
2. No attack surface exposure through Charon application
3. Hardcoded, internal-only usage of affected utilities
4. Multiple layers of defense-in-depth mitigation
5. Active monitoring and automated remediation process
The decision to accept these risks is consistent with industry best practices for vulnerability management in containerized applications pending upstream security patches.
---
## References
### Official Sources
- [Alpine Linux Security Team](https://security.alpinelinux.org/)
- [Alpine Security Advisories](https://security.alpinelinux.org/vuln)
- [National Vulnerability Database (NVD)](https://nvd.nist.gov/)
- [MITRE CVE Database](https://cve.mitre.org/)
- [CISA Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
### Project Documentation
- [Charon Security Policy](../../SECURITY.md)
- [Supply Chain Security Documentation](./supply-chain-no-cache-solution.md)
- [Accepted Risks (Legacy)](./accepted-risks.md)
- [PR #461 Remediation Plan](../plans/current_spec.md)
### Standards & Frameworks
- [NIST SP 800-53 Rev 5](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
- [OWASP Risk Rating Methodology](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology)
- [CIS Controls v8](https://www.cisecurity.org/controls/v8)
- [ISO 27001:2022](https://www.iso.org/standard/27001)
---
**Document Version**: 1.0
**Last Updated**: 2026-01-13
**Next Review**: 2026-02-13

192
docs/security/accepted-risks.md
View File

@@ -1,192 +0,0 @@
# Accepted Security Risks
This document tracks security vulnerabilities that have been assessed and accepted as low-risk, pending upstream patches.
---
## Alpine Linux Base Image Vulnerabilities
### CVE-2025-60876 (busybox, busybox-binsh, ssl_client)
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-11
**Severity**: Medium
**CVSS**: TBD
#### Affected Components
- **busybox**: 1.37.0-r20
- **busybox-binsh**: 1.37.0-r20
- **ssl_client**: 1.37.0-r20
#### Vulnerability Description
CVE-2025-60876 affects multiple busybox utilities in Alpine Linux 3.21. As of 2026-01-11, no patch is available from Alpine Security Team.
#### Risk Assessment
**Exploitability**: Low
- Requires local shell access or specific network conditions
- Not directly exposed through application APIs
- Container isolation limits attack surface
**Impact**: Limited
- busybox provides minimal shell utilities used for healthchecks and diagnostics
- ssl_client used internally by Alpine package manager
- No direct user input processing through these utilities
**Mitigation Strategies**:
1. **Container Isolation**: Running in containerized environment limits local access
2. **Network Policies**: Ingress/egress rules restrict network-based exploitation
3. **Non-Privileged Container**: Runs as non-root user (caddy user)
4. **Read-Only Filesystem**: Application code and binaries mounted read-only where possible
#### Monitoring Plan
- **Frequency**: Daily checks of Alpine Security advisories
- **Source**: <https://security.alpinelinux.org/vuln>
- **Alert Trigger**: Patch release for CVE-2025-60876
- **Action**: Rebuild Docker image with updated Alpine base
#### Remediation Timeline
- **Expected Upstream Fix**: TBD (monitoring Alpine Security Team)
- **Automatic Remediation**: Will be included in next Docker rebuild after Alpine patch
- **Review Date**: 2026-02-11 (30 days) or upon patch release, whichever is sooner
---
### CVE-2025-10966 (curl/libcurl)
**Status**: ⚠️ ACCEPTED - Pending Alpine Security Patch
**Date Accepted**: 2026-01-11
**Severity**: Medium
**CVSS**: TBD
#### Affected Components
- **curl**: 8.14.1-r2
- **libcurl**: 8.14.1-r2 (implicit)
#### Vulnerability Description
CVE-2025-10966 affects libcurl in Alpine Linux 3.21. As of 2026-01-11, no patch is available from Alpine Security Team.
#### Risk Assessment
**Exploitability**: Medium
- Requires network access and specific request patterns
- curl used only in healthcheck scripts and manual debugging
- Not exposed directly to user input
**Impact**: Limited
- curl invoked only for internal health monitoring
- No user-controlled URLs passed to curl
- Healthcheck scripts use hardcoded localhost endpoints
**Mitigation Strategies**:
1. **Limited Usage**: curl only used for internal healthchecks (`http://localhost:8080/api/v1/health`)
2. **No User Input**: All curl invocations use hardcoded, internal URLs
3. **Container Isolation**: Network policies restrict external access
4. **Alternative Available**: Application can fall back to TCP socket checks
#### Monitoring Plan
- **Frequency**: Daily checks of Alpine Security advisories
- **Source**: <https://security.alpinelinux.org/vuln>
- **Alert Trigger**: Patch release for CVE-2025-10966
- **Action**: Rebuild Docker image with updated Alpine base
#### Remediation Timeline
- **Expected Upstream Fix**: TBD (monitoring Alpine Security Team)
- **Automatic Remediation**: Will be included in next Docker rebuild after Alpine patch
- **Review Date**: 2026-02-11 (30 days) or upon patch release, whichever is sooner
---
## Review Schedule
### Quarterly Security Review
- **Next Review**: 2026-04-11
- **Scope**: Re-assess all accepted risks, evaluate alternative base images
- **Attendees**: Security team, DevOps, Engineering Director
### Monthly Monitoring
- **Frequency**: First Monday of each month
- **Scope**: Check Alpine and upstream security advisories
- **Action**: Update this document if status changes
### Continuous Monitoring
- **Automated**: GitHub Dependabot, Renovate Bot
- **Manual**: Daily check of Alpine security feed during active incident periods
---
## Escalation Criteria
Accepted risks will be escalated to immediate remediation if:
1. **Severity Upgrade**: CVE severity upgraded to High or Critical
2. **Active Exploitation**: Evidence of active exploitation in the wild
3. **CISA KEV**: Added to CISA Known Exploited Vulnerabilities catalog
4. **Proof of Concept**: Public PoC demonstrating exploitability in containers
5. **Compliance Requirement**: Regulatory or audit requirement to remediate
---
## Alternative Mitigation Considered
### Switch to Distroless Base Image
**Status**: Under Evaluation
**Timeline**: Q1 2026
**Pros**:
- Minimal attack surface (no shell, no package manager)
- Faster security patches from Google
- Smaller image size
**Cons**:
- Debugging challenges (no shell access)
- May require custom healthcheck mechanisms
- Migration effort required
**Decision**: Continue monitoring Alpine CVEs while evaluating distroless for Q1 2026.
---
## Approval
**Approved By**: Engineering Director
**Date**: 2026-01-11
**Review Scheduled**: 2026-02-11
**Rationale**: The assessed risk from these Medium-severity Alpine CVEs is acceptable given:
1. Low exploitability in containerized environment
2. No upstream patches available
3. Effective mitigation strategies in place
4. Active monitoring for patches
5. No critical or high-severity vulnerabilities present
---
## References
- [Alpine Linux Security](https://security.alpinelinux.org/)
- [CVE-2025-60876 Details](https://nvd.nist.gov/vuln/detail/CVE-2025-60876) (pending NVD update)
- [CVE-2025-10966 Details](https://nvd.nist.gov/vuln/detail/CVE-2025-10966) (pending NVD update)
- [Supply Chain Remediation Plan](./supply-chain-no-cache-solution.md)
- [NIST SP 800-53: Security Controls](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)

215
docs/security/codeql-scanning.md
View File

@@ -1,215 +0,0 @@
# CodeQL Security Scanning Guide
## Overview
Charon uses GitHub's CodeQL for static application security testing (SAST). CodeQL analyzes code to find security vulnerabilities and coding errors.
## Quick Start
### Run CodeQL Locally (CI-Aligned)
**Via VS Code Tasks:**
1. Open Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`)
2. Type "Tasks: Run Task"
3. Select:
- `Security: CodeQL Go Scan (CI-Aligned)` - Scan backend
- `Security: CodeQL JS Scan (CI-Aligned)` - Scan frontend
- `Security: CodeQL All (CI-Aligned)` - Scan both
**Via Pre-Commit:**
```bash
# Quick security check (govulncheck - 5s)
pre-commit run security-scan --all-files
# Full CodeQL scan (2-3 minutes)
pre-commit run codeql-go-scan --all-files
pre-commit run codeql-js-scan --all-files
pre-commit run codeql-check-findings --all-files
```
**Via Command Line:**
```bash
# Go scan
codeql database create codeql-db-go --language=go --source-root=backend --overwrite
codeql database analyze codeql-db-go \
codeql/go-queries:codeql-suites/go-security-and-quality.qls \
--format=sarif-latest --output=codeql-results-go.sarif
# JavaScript/TypeScript scan
codeql database create codeql-db-js --language=javascript --source-root=frontend --overwrite
codeql database analyze codeql-db-js \
codeql/javascript-queries:codeql-suites/javascript-security-and-quality.qls \
--format=sarif-latest --output=codeql-results-js.sarif
```
### View Results
**Method 1: VS Code SARIF Viewer (Recommended)**
1. Install extension: `MS-SarifVSCode.sarif-viewer`
2. Open `codeql-results-go.sarif` or `codeql-results-js.sarif`
3. Navigate findings with inline annotations
**Method 2: Command Line (jq)**
```bash
# Summary
jq '.runs[].results | length' codeql-results-go.sarif
# Details
jq -r '.runs[].results[] | "\(.level): \(.message.text) (\(.locations[0].physicalLocation.artifactLocation.uri):\(.locations[0].physicalLocation.region.startLine))"' codeql-results-go.sarif
```
**Method 3: GitHub Security Tab**
- CI automatically uploads results to: `https://github.com/YourOrg/Charon/security/code-scanning`
## Understanding Query Suites
Charon uses the **security-and-quality** suite (GitHub Actions default):
| Suite | Go Queries | JS Queries | Use Case |
|-------|-----------|-----------|----------|
| `security-extended` | 39 | 106 | Security-only, faster |
| `security-and-quality` | 61 | 204 | Security + quality, comprehensive (CI default) |
⚠️ **Important:** Local scans MUST use `security-and-quality` to match CI behavior.
## Severity Levels
- 🔴 **Error (High/Critical):** Must fix before merge - CI will fail
- 🟡 **Warning (Medium):** Should fix - CI continues
- 🔵 **Note (Low/Info):** Consider fixing - CI continues
## Common Issues & Fixes
### Issue: "CWE-918: Server-Side Request Forgery (SSRF)"
**Location:** `backend/internal/api/handlers/url_validator.go`
**Fix:**
```go
// BAD: Unrestricted URL
resp, err := http.Get(userProvidedURL)
// GOOD: Validate against allowlist
if !isAllowedHost(userProvidedURL) {
return ErrSSRFAttempt
}
resp, err := http.Get(userProvidedURL)
```
**Reference:** [docs/security/ssrf-protection.md](ssrf-protection.md)
### Issue: "CWE-079: Cross-Site Scripting (XSS)"
**Location:** `frontend/src/components/...`
**Fix:**
```typescript
// BAD: Unsafe HTML rendering
element.innerHTML = userInput;
// GOOD: Safe text content
element.textContent = userInput;
// GOOD: Sanitized HTML (if HTML is required)
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);
```
### Issue: "CWE-089: SQL Injection"
**Fix:** Use parameterized queries (GORM handles this automatically)
```go
// BAD: String concatenation
db.Raw("SELECT * FROM users WHERE name = '" + userName + "'")
// GOOD: Parameterized query
db.Where("name = ?", userName).Find(&users)
```
## CI/CD Integration
### When CodeQL Runs
- **Push:** Every commit to `main`, `development`, `feature/*`
- **Pull Request:** Every PR to `main`, `development`
- **Schedule:** Weekly scan on Monday at 3 AM UTC
### CI Behavior
✅ **Allowed to merge:**
- No findings
- Only warnings/notes
- Forked PRs (security scanning skipped for permission reasons)
❌ **Blocked from merge:**
- Any error-level (high/critical) findings
- CodeQL analysis failure
### Viewing CI Results
1. **PR Checks:** See "CodeQL analysis (go)" and "CodeQL analysis (javascript-typescript)" checks
2. **Security Tab:** Navigate to repo → Security → Code scanning alerts
3. **Workflow Summary:** Click on failed check → View job summary
## Troubleshooting
### "CodeQL passes locally but fails in CI"
**Cause:** Using wrong query suite locally
**Fix:** Ensure tasks use `security-and-quality`:
```bash
codeql database analyze DB_PATH \
codeql/LANGUAGE-queries:codeql-suites/LANGUAGE-security-and-quality.qls \
...
```
### "SARIF file not found"
**Cause:** Database creation or analysis failed
**Fix:**
1. Check terminal output for errors
2. Ensure CodeQL is installed: `codeql version`
3. Verify source-root exists: `ls backend/` or `ls frontend/`
### "Too many findings to fix"
**Strategy:**
1. Fix all **error** level first (CI blockers)
2. Create issues for **warning** level (non-blocking)
3. Document **note** level for future consideration
**Suppress false positives:**
```go
// codeql[go/sql-injection] - Safe: input is validated by ACL
db.Raw(query).Scan(&results)
```
## Performance Tips
- **Incremental Scans:** CodeQL caches databases, second run is faster
- **Parallel Execution:** Use `--threads=0` for auto-detection
- **CI Only:** Run full scans in CI, quick checks locally
## References
- [CodeQL Documentation](https://codeql.github.com/docs/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [CWE Database](https://cwe.mitre.org/)
- [Charon Security Policy](../SECURITY.md)

1431
docs/security/ssrf-protection.md
View File

File diff suppressed because it is too large Load Diff

441
docs/security/supply-chain-no-cache-solution.md
View File

@@ -1,441 +0,0 @@
# Supply Chain Security: Vulnerability Remediation Strategy
**Date**: 2026-01-11
**PR**: [#461 - DNS Challenge Support](https://github.com/Wikid82/Charon/pull/461)
**Status**: ⚠️ 8 Medium Vulnerabilities Identified (Not False Positives)
---
## Executive Summary
After implementing `--no-cache` builds, the supply chain scan still reports **8 Medium vulnerabilities**. Investigation reveals these are **actual runtime dependencies**, not false positives from cached layers.
**Vulnerability Breakdown**:
- **3 Alpine APK packages** (busybox, curl, ssl_client) - CVE-2025-60876, CVE-2025-10966 (no fixes available)
- **2 Go dependencies** (golang.org/x/crypto v0.42.0) - GHSA-j5w8-q4qc-rx2x, GHSA-f6x5-jh6r-wrfv (fix available: v0.45.0)
**Current Status**:
- ✅ No-cache builds implemented successfully
- ⚠️ Alpine base image vulnerabilities have no upstream patches yet
- 🔧 golang.org/x/crypto requires dependency update
---
## Vulnerability Analysis
### Actual Vulnerabilities Found (Not False Positives)
#### 1. Alpine Base Image - busybox (CVE-2025-60876)
**Affected Packages**: busybox, busybox-binsh, ssl_client
**Current Version**: 1.37.0-r20
**Fixed Version**: None available
**Severity**: Medium
**Details**: CVE-2025-60876 affects busybox utilities in Alpine 3.21. No patch is available yet from Alpine upstream.
**Impact**:
- Affects base image utilities (not directly used by application)
- Busybox provides minimal shell and utilities in Alpine
- Low exploitability in containerized environment
**Recommendation**: Monitor Alpine security advisories for patch release.
#### 2. Alpine Base Image - curl (CVE-2025-10966)
**Current Version**: 8.14.1-r2
**Fixed Version**: None available
**Severity**: Medium
**Details**: CVE-2025-10966 affects libcurl in Alpine 3.21. No patch is available yet from Alpine upstream.
**Impact**:
- curl is used by healthcheck scripts
- Medium severity with limited attack surface
- Requires network access to exploit
**Recommendation**: Monitor Alpine security advisories for patch release.
#### 3. Go Dependencies - golang.org/x/crypto (GHSA-j5w8-q4qc-rx2x, GHSA-f6x5-jh6r-wrfv)
**Current Version**: v0.42.0 (transitive dependency)
**Fixed Version**: v0.45.0
**Severity**: Medium
**Details**: Two GitHub Security Advisories affecting golang.org/x/crypto v0.42.0:
- GHSA-j5w8-q4qc-rx2x: SSH connection handling vulnerability
- GHSA-f6x5-jh6r-wrfv: SSH key parsing vulnerability
**Dependency Chain**:
```
github.com/go-playground/validator/v10@v10.28.0
└─> golang.org/x/crypto@v0.42.0 (VULNERABLE)
Direct dependency: golang.org/x/crypto@v0.46.0 (SAFE)
```
**Impact**:
- Transitive dependency from go-playground/validator
- validator library used for input validation in API handlers
- Medium severity - requires specific conditions to exploit
**Remediation**: Force upgrade via go.mod replace directive or wait for upstream validator update.
---
## Root Cause Analysis
### Why No-Cache Didn't Eliminate These
The `--no-cache` implementation **worked correctly**. These vulnerabilities are in the **runtime image**, not in build cache layers:
1. **Alpine packages** are installed in the final Docker image via `RUN apk add`
2. **golang.org/x/crypto** is compiled into the `charon` binary as a transitive dependency
3. **Not cached layers** - these are actual production dependencies
### What No-Cache Did Accomplish
✅ Eliminated potential false positives from builder stage caching
✅ Ensured fresh base image pulls with latest patches
✅ Provided clean, reproducible builds
✅ Accurate SBOM reflecting actual runtime dependencies
---
## Remediation Strategy
### Immediate Actions (Can Implement Now)
#### 1. Force golang.org/x/crypto Upgrade
Add a replace directive to force the vulnerable transitive dependency to use the patched version:
```go
// backend/go.mod
module github.com/Wikid82/charon/backend
go 1.25.5
// Force all transitive dependencies to use patched version
replace golang.org/x/crypto v0.42.0 => golang.org/x/crypto v0.45.0
require (
// ... existing dependencies
)
```
**Expected Impact**: Eliminates 2-4 of the 8 Medium vulnerabilities (the golang.org/x/crypto issues).
**Testing Required**:
- ✅ Backend unit tests
- ✅ Integration tests
- ✅ Validate validator/v10 compatibility
#### 2. Document Accepted Risk for Alpine CVEs
Since Alpine has not released patches for CVE-2025-60876 and CVE-2025-10966:
1. Create risk acceptance document in `docs/security/accepted-risks.md`
2. Document mitigation strategies:
- busybox/ssl_client: Not directly invoked by application code
- curl: Only used in healthchecks, no user input processing
3. Set monitoring alerts for Alpine security updates
4. Plan to update base image when patches are released
### Short-Term Actions (Monitor & Update)
#### 3. Monitor Alpine Security Advisories
**Action Plan**:
1. Subscribe to Alpine Linux security mailing list
2. Check <https://security.alpinelinux.org/vuln> daily
3. When patches are released:
```bash
# Update Dockerfile base image
FROM caddy:2-alpine # This will pull the latest Alpine patch
```
4. Rebuild and re-scan to verify resolution
#### 4. Monitor go-playground/validator Updates
**Action Plan**:
1. Check <https://github.com/go-playground/validator/releases> weekly
2. When validator releases version with golang.org/x/crypto@v0.45.0+:
```bash
cd backend
go get -u github.com/go-playground/validator/v10@latest
go mod tidy
```
3. Remove the replace directive from go.mod
4. Re-run tests and supply chain scan
### Long-Term Actions (Proactive Security)
### Long-Term Actions (Proactive Security)
#### 5. Implement Automated Dependency Updates
**Tools to Consider**:
- Renovate Bot (already configured) - increase update frequency
- Dependabot for Go modules
- Automated security patch PRs
**Configuration**:
```json
// .github/renovate.json
{
"vulnerabilityAlerts": {
"enabled": true,
"schedule": "at any time"
},
"go": {
"enabled": true,
"schedule": "weekly"
}
}
```
#### 6. Alternative Base Images
**Research Options**:
1. **Distroless** (Google) - Minimal attack surface, no shell
2. **Alpine with chainguard** - Hardened Alpine with faster security patches
3. **Wolfi** (Chainguard) - Modern, security-first distribution
**Evaluation Criteria**:
- Security patch velocity
- Compatibility with Caddy
- Image size impact
- Build time impact
---
## Implementation Plan
### Phase 1: Immediate Remediation (This PR)
1. ✅ Add replace directive for golang.org/x/crypto
2. ✅ Run full test suite
3. ✅ Verify supply chain scan shows reduction to 3-4 Medium vulnerabilities
4. ✅ Document accepted risks for Alpine CVEs
### Phase 2: Monitoring & Updates (Next 2 Weeks)
1. ⏳ Monitor Alpine security advisories daily
2. ⏳ Check go-playground/validator for updates weekly
3. ⏳ Set up automated alerts for CVE-2025-60876 and CVE-2025-10966
4. ⏳ Review Renovate configuration for security updates
### Phase 3: Long-Term Hardening (Next Quarter)
1. ⏳ Evaluate alternative base images (distroless, wolfi)
2. ⏳ Implement automated security patch workflow
3. ⏳ Add security regression tests to CI/CD
4. ⏳ Quarterly security posture review
---
## No-Cache Implementation (Completed)
### Files Modified
1. `.github/workflows/docker-build.yml`
- Added `no-cache: true` to `build-and-push` step
- Removed GitHub Actions cache configuration
- Added `--no-cache` to PR-specific builds
2. `.github/workflows/waf-integration.yml`
- Added `--no-cache` flag to integration test builds
3. `.github/workflows/security-weekly-rebuild.yml`
- Already using `no-cache` for scheduled scans
### What No-Cache Accomplished
✅ **Clean Builds**: No cached layers from previous builds
✅ **Fresh Base Images**: Always pulls latest Alpine patches
✅ **Accurate SBOMs**: Only runtime dependencies included
✅ **Reproducible Builds**: Consistent results across runs
---
## Testing & Validation
### Test Plan for golang.org/x/crypto Upgrade
```bash
# 1. Add replace directive to backend/go.mod
echo 'replace golang.org/x/crypto v0.42.0 => golang.org/x/crypto v0.45.0' >> backend/go.mod
# 2. Update dependencies
cd backend
go mod tidy
# 3. Run test suite
go test ./... -v -cover
# 4. Build Docker image
docker build --no-cache -t charon:security-test .
# 5. Scan for vulnerabilities
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy:latest image charon:security-test \
--severity MEDIUM,HIGH,CRITICAL
# 6. Verify golang.org/x/crypto vulnerabilities are resolved
```
### Expected Results
**Before Replace Directive**:
```
Medium: 8 (busybox x3, curl x1, golang.org/x/crypto x4)
```
**After Replace Directive**:
```
Medium: 4 (busybox x3, curl x1)
```
### Rollback Plan
If the replace directive causes test failures:
```bash
# Remove replace directive
cd backend
git checkout backend/go.mod backend/go.sum
# Rebuild and test
go mod tidy
go test ./...
```
---
## Monitoring and Maintenance
### Ongoing Monitoring
1. **Weekly Security Scans**: Automated via `security-weekly-rebuild.yml`
2. **PR-Level Scans**: Every pull request gets supply chain verification
3. **SARIF Upload**: Results uploaded to GitHub Security tab for tracking
4. **Dependabot**: Automated dependency updates for Go modules and npm packages
### Success Metrics
- ✅ 0 false positive vulnerabilities from cached layers
- ✅ 100% SBOM accuracy (only production dependencies)
- ✅ Build time increase < 5 minutes
- ✅ All security scans passing for PRs
### Review Schedule
- **Monthly**: Review build time impact and optimization opportunities
- **Quarterly**: Assess if partial caching can be re-enabled for dev branches
- **Annual**: Full security posture review and workflow optimization
---
## References
- [Docker Build Documentation](https://docs.docker.com/engine/reference/commandline/build/)
- [Docker Buildx Caching](https://docs.docker.com/build/cache/)
- [Trivy Image Scanning](https://aquasecurity.github.io/trivy/)
- [Grype Vulnerability Scanner](https://github.com/anchore/grype)
- [GitHub Actions: Docker Build](https://github.com/docker/build-push-action)
---
## Conclusion
Implementing `--no-cache` builds across all workflows eliminates false positive vulnerability reports from cached Go module layers. This provides accurate security posture reporting, clean SBOMs, and compliance-ready artifacts. The trade-off of slightly longer build times is acceptable for the security benefits gained.
**Next Steps**:
1. ✅ Changes committed to `docker-build.yml` and `waf-integration.yml`
2. ⏳ Wait for next PR build to validate clean scan results
3. ⏳ Monitor build time impact and adjust if needed
4. ⏳ Update this document with actual performance metrics after deployment
---
**Authored by**: Engineering Director (Management Agent)
**Review Status**: Ready for implementation
**Approval**: Pending user confirmation
---
## Security Posture Summary
### Current State (PR #461 - Build 20901537001)
**Vulnerability Status**: ⚠️ 8 Medium
**Critical/High**: ✅ 0
**Build Quality**: ✅ No-cache implemented, accurate scanning
| Package | Version | CVE/GHSA | Severity | Fix Available | Action |
|---------|---------|----------|----------|---------------|--------|
| busybox | 1.37.0-r20 | CVE-2025-60876 | Medium | ❌ No | Monitor Alpine |
| busybox-binsh | 1.37.0-r20 | CVE-2025-60876 | Medium | ❌ No | Monitor Alpine |
| ssl_client | 1.37.0-r20 | CVE-2025-60876 | Medium | ❌ No | Monitor Alpine |
| curl | 8.14.1-r2 | CVE-2025-10966 | Medium | ❌ No | Monitor Alpine |
| golang.org/x/crypto | v0.42.0 | GHSA-j5w8-q4qc-rx2x | Medium | ✅ v0.45.0 | Add replace directive |
| golang.org/x/crypto | v0.42.0 | GHSA-j5w8-q4qc-rx2x | Medium | ✅ v0.45.0 | (duplicate) |
| golang.org/x/crypto | v0.42.0 | GHSA-f6x5-jh6r-wrfv | Medium | ✅ v0.45.0 | Add replace directive |
| golang.org/x/crypto | v0.42.0 | GHSA-f6x5-jh6r-wrfv | Medium | ✅ v0.45.0 | (duplicate) |
### Risk Assessment
**Alpine CVEs (3 unique vulnerabilities in 4 packages)**:
- **Exploitability**: Low (requires local access or specific network conditions)
- **Impact**: Limited (utilities not directly exposed to user input)
- **Mitigation**: Containerization limits attack surface
- **Status**: **ACCEPTED RISK** - Monitor for upstream patches
**golang.org/x/crypto (2 unique vulnerabilities, 4 entries due to scan reporting)**:
- **Exploitability**: Medium (requires SSH connection handling)
- **Impact**: Medium (transitive dependency from validator)
- **Mitigation**: Add replace directive to force v0.45.0
- **Status**: **ACTIONABLE** - Implement in this PR
### Recommended Actions Priority
1. **🔴 HIGH PRIORITY**: Implement golang.org/x/crypto replace directive (reduces to 4 Medium)
2. **🟡 MEDIUM PRIORITY**: Document accepted risk for Alpine CVEs
3. **🟢 LOW PRIORITY**: Monitor Alpine security advisories for patches
---
## Next Steps
1. ✅ No-cache builds implemented and validated
2. ⏳ Add replace directive for golang.org/x/crypto v0.45.0
3. ⏳ Run full test suite to validate compatibility
4. ⏳ Create accepted-risks.md for Alpine CVEs
5. ⏳ Monitor Alpine and validator upstream for patches
6. ⏳ Re-scan to verify reduction to 4 Medium vulnerabilities
**Conclusion**: The `--no-cache` implementation worked as intended. The 8 Medium vulnerabilities are actual runtime dependencies, not false positives. We can immediately remediate 4 of them (golang.org/x/crypto) and must accept risk for the remaining 4 Alpine CVEs until upstream patches are released.

147
docs/security/websocket-auth-security.md
View File

@@ -1,147 +0,0 @@
---
title: WebSocket Authentication Security
description: Security documentation for WebSocket authentication in Charon. HttpOnly cookie implementation and token protection.
---
## WebSocket Authentication Security
### Overview
This document explains the security improvements made to WebSocket authentication in Charon to prevent JWT tokens from being exposed in access logs.
### Security Issue
### Before (Insecure)
Previously, WebSocket connections authenticated by passing the JWT token as a query parameter:
```
wss://example.com/api/v1/logs/live?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```
**Security Risk:**
- Query parameters are logged in web server access logs (Caddy, nginx, Apache, etc.)
- Tokens appear in proxy logs
- Tokens may be stored in browser history
- Tokens can be captured in monitoring and telemetry systems
- An attacker with access to these logs can replay the token to impersonate a user
### After (Secure)
WebSocket connections now authenticate using HttpOnly cookies:
```
wss://example.com/api/v1/logs/live?source=waf&level=error
```
The browser automatically sends the `auth_token` cookie with the WebSocket upgrade request.
**Security Benefits:**
- ✅ HttpOnly cookies are **not logged** by web servers
- ✅ HttpOnly cookies **cannot be accessed** by JavaScript (XSS protection)
- ✅ Cookies are **not visible** in browser history
- ✅ Cookies are **not captured** in URL-based monitoring
- ✅ Token replay attacks are mitigated (tokens still have expiration)
## Implementation Details
### Frontend Changes
**Location:** `frontend/src/api/logs.ts`
Removed:
```typescript
const token = localStorage.getItem('charon_auth_token');
if (token) {
params.append('token', token);
}
```
The browser automatically sends the `auth_token` cookie when establishing WebSocket connections due to:
1. The cookie is set by the backend during login with `HttpOnly`, `Secure`, and `SameSite` flags
2. The axios client has `withCredentials: true`, enabling cookie transmission
### Backend Changes
**Location:** `backend/internal/api/middleware/auth.go`
Authentication priority order:
1. **Authorization header** (Bearer token) - for API clients
2. **auth_token cookie** (HttpOnly) - **preferred for browsers and WebSockets**
3. **token query parameter** - **deprecated**, kept for backward compatibility only
The query parameter fallback is marked as deprecated and will be removed in a future version.
### Cookie Configuration
**Location:** `backend/internal/api/handlers/auth_handler.go`
The `auth_token` cookie is set with security best practices:
- **HttpOnly**: `true` - prevents JavaScript access (XSS protection)
- **Secure**: `true` (in production with HTTPS) - prevents transmission over HTTP
- **SameSite**: `Strict` (HTTPS) or `Lax` (HTTP/IP) - CSRF protection
- **Path**: `/` - available for all routes
- **MaxAge**: 24 hours - automatic expiration
## Verification
### Test Coverage
**Location:** `backend/internal/api/middleware/auth_test.go`
- `TestAuthMiddleware_Cookie` - verifies cookie authentication works
- `TestAuthMiddleware_QueryParamFallback` - verifies deprecated query param still works
- `TestAuthMiddleware_PrefersCookieOverQueryParam` - verifies cookie is prioritized over query param
- `TestAuthMiddleware_PrefersAuthorizationHeader` - verifies header takes highest priority
### Log Verification
To verify tokens are not logged:
1. **Before the fix:** Check Caddy access logs for token exposure:
```bash
docker logs charon 2>&1 | grep "token=" | grep -o "token=[^&]*"
```
Would show: `token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...`
2. **After the fix:** Check that WebSocket URLs are clean:
```bash
docker logs charon 2>&1 | grep "/logs/live\|/cerberus/logs/ws"
```
Shows: `/api/v1/logs/live?source=waf&level=error` (no token)
## Migration Path
### For Users
No action required. The change is transparent:
- Login sets the HttpOnly cookie
- WebSocket connections automatically use the cookie
- Existing sessions continue to work
### For API Clients
API clients using Authorization headers are unaffected.
### Deprecation Timeline
1. **Current:** Query parameter authentication is deprecated but still functional
2. **Future (v2.0):** Query parameter authentication will be removed entirely
3. **Recommendation:** Any custom scripts or tools should migrate to using Authorization headers or cookie-based authentication
## Related Documentation
- [Authentication Flow](../plans/prev_spec_websocket_fix_dec16.md#authentication-flow)
- [Security Best Practices](https://owasp.org/www-community/HttpOnly)
- [WebSocket Security](https://datatracker.ietf.org/doc/html/rfc6455#section-10)