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

feat: add nightly branch workflow

Browse Source
This commit is contained in:
GitHub Actions
2026-01-13 22:11:28 +00:00
parent d27c925ba5
commit 4adcd9eda1
187 changed files with 8897 additions and 1614 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/implementation/SSRF_REMEDIATION_COMPLETE.md
View File

@@ -13,6 +13,7 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
### Phase 1: Security Utility Package ✅
**Files Created:**
- `/backend/internal/security/url_validator.go` (195 lines)
- `ValidateExternalURL()` - Main validation function with comprehensive SSRF protection
- `isPrivateIP()` - Helper checking 13+ CIDR blocks (RFC 1918, loopback, link-local, AWS/GCP metadata ranges)
@@ -24,6 +25,7 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
- Real-world webhook format tests (Slack, Discord, GitHub)
**Defense-in-Depth Layers:**
1. URL parsing and format validation
2. Scheme enforcement (HTTPS-only for production)
3. DNS resolution with timeout
@@ -31,6 +33,7 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
5. HTTP client configuration (redirects, timeouts)
**Blocked IP Ranges:**
- RFC 1918 private networks: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- Loopback: 127.0.0.0/8, ::1/128
- Link-local: 169.254.0.0/16 (AWS/GCP metadata), fe80::/10
@@ -40,9 +43,11 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
### Phase 2: Vulnerability Fixes ✅
#### CRITICAL-001: Security Notification Webhook ✅
**Impact**: Attacker-controlled webhook URLs could access internal services
**Files Modified:**
1. `/backend/internal/services/security_notification_service.go`
- Added SSRF validation to `sendWebhook()` (lines 95-120)
- Logging: SSRF attempts logged with HIGH severity
@@ -56,22 +61,27 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
**Protection:** Dual-layer validation (at save time AND at send time)
#### CRITICAL-002: Update Service GitHub API ✅
**Impact**: Compromised update URLs could redirect to malicious servers
**File Modified:** `/backend/internal/services/update_service.go`
- Modified `SetAPIURL()` - now returns error (breaking change)
- Validation: HTTPS required for GitHub domains
- Allowlist: `api.github.com`, `github.com`
- Test exception: Accepts localhost for `httptest.Server` compatibility
**Test Files Updated:**
- `/backend/internal/services/update_service_test.go`
- `/backend/internal/api/handlers/update_handler_test.go`
#### HIGH-001: CrowdSec Hub URL Validation ✅
**Impact**: Malicious preset URLs could fetch from attacker-controlled servers
**File Modified:** `/backend/internal/crowdsec/hub_sync.go`
- Created `validateHubURL()` function (60 lines)
- Modified `fetchIndexHTTPFromURL()` - validates before request
- Modified `fetchWithLimitFromURL()` - validates before request
@@ -81,9 +91,11 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
**Protection:** All hub fetches now validate URLs through centralized function
#### MEDIUM-001: CrowdSec LAPI URL Validation ✅
**Impact**: Malicious LAPI URLs could leak decision data to external servers
**File Modified:** `/backend/internal/crowdsec/registration.go`
- Created `validateLAPIURL()` function (50 lines)
- Modified `EnsureBouncerRegistered()` - validates before requests
- Security-first approach: **Only localhost allowed**
@@ -94,12 +106,14 @@ Successfully implemented comprehensive Server-Side Request Forgery (SSRF) protec
## Test Results
### Security Package Tests ✅
```
ok github.com/Wikid82/charon/backend/internal/security 0.107s
coverage: 90.4% of statements
```
**Test Suites:**
- TestValidateExternalURL_BasicValidation (14 cases)
- TestValidateExternalURL_LocalhostHandling (6 cases)
- TestValidateExternalURL_PrivateIPBlocking (8 cases)
@@ -108,18 +122,21 @@ coverage: 90.4% of statements
- TestValidateExternalURL_Options (4 cases)
### CrowdSec Tests ✅
```
ok github.com/Wikid82/charon/backend/internal/crowdsec 12.590s
coverage: 82.1% of statements
```
All 97 CrowdSec tests passing, including:
- Hub sync validation tests
- Registration validation tests
- Console enrollment tests
- Preset caching tests
### Services Tests ✅
```
ok github.com/Wikid82/charon/backend/internal/services 41.727s
coverage: 82.9% of statements
@@ -128,12 +145,14 @@ coverage: 82.9% of statements
Security notification service tests passing.
### Static Analysis ✅
```bash
$ go vet ./...
# No warnings - clean
```
### Overall Coverage
```
total: (statements) 84.8%
```
@@ -143,6 +162,7 @@ total: (statements) 84.8%
## Security Improvements
### Before
- ❌ No URL validation
- ❌ Webhook URLs accepted without checks
- ❌ Update service URLs unvalidated
@@ -150,6 +170,7 @@ total: (statements) 84.8%
- ❌ LAPI URLs could point anywhere
### After
- ✅ Comprehensive SSRF protection utility
- ✅ Dual-layer webhook validation (save + send)
- ✅ GitHub domain allowlist for updates
@@ -161,10 +182,12 @@ total: (statements) 84.8%
## Files Changed Summary
### New Files (2)
1. `/backend/internal/security/url_validator.go`
2. `/backend/internal/security/url_validator_test.go`
### Modified Files (7)
1. `/backend/internal/services/security_notification_service.go`
2. `/backend/internal/api/handlers/security_notifications.go`
3. `/backend/internal/services/update_service.go`
@@ -178,16 +201,19 @@ total: (statements) 84.8%
## Pending Work
### MEDIUM-002: CrowdSec Handler Validation ⚠️
**Status**: Not yet implemented (lower priority)
**File**: `/backend/internal/crowdsec/crowdsec_handler.go`
**Impact**: Potential SSRF in CrowdSec decision endpoints
**Reason for Deferral:**
- MEDIUM priority (lower risk)
- Requires understanding of handler flow
- Phase 1 & 2 addressed all CRITICAL and HIGH issues
### Handler Test Suite Issue ⚠️
**Status**: Pre-existing test failure (unrelated to SSRF work)
**File**: `/backend/internal/api/handlers/`
**Coverage**: 84.4% (passing)
@@ -196,15 +222,19 @@ total: (statements) 84.8%
## Deployment Notes
### Breaking Changes
- `update_service.SetAPIURL()` now returns error (was void)
- All callers updated in this implementation
- External consumers will need to handle error return
### Configuration
No configuration changes required. All validations use secure defaults.
### Monitoring
SSRF attempts are logged with structured fields:
```go
logger.Log().WithFields(logrus.Fields{
"url": blockedURL,
@@ -236,6 +266,7 @@ logger.Log().WithFields(logrus.Fields{
## Performance Impact
Minimal overhead:
- URL parsing: ~10-50μs
- DNS resolution: ~50-200ms (cached by OS)
- IP validation: <1μs
@@ -245,9 +276,11 @@ Validation is only performed when URLs are updated (configuration changes), not
## Security Assessment
### OWASP Top 10 Compliance
- **A10:2021 - Server-Side Request Forgery (SSRF)**: ✅ Mitigated
### Defense-in-Depth Layers
1. ✅ Input validation (URL format, scheme)
2. ✅ Allowlisting (known safe domains)
3. ✅ DNS resolution with timeout
@@ -256,6 +289,7 @@ Validation is only performed when URLs are updated (configuration changes), not
6. ✅ Fail-fast principle (validate on save)
### Residual Risk
- **MEDIUM-002**: Deferred handler validation (lower priority)
- **Test Coverage**: 84.8% vs 85% target (0.2% gap, non-SSRF code)
@@ -266,12 +300,14 @@ Validation is only performed when URLs are updated (configuration changes), not
All critical and high-priority SSRF vulnerabilities have been addressed with comprehensive validation, testing, and logging. The implementation follows security best practices with defense-in-depth protection and user-friendly error handling.
**Next Steps:**
1. Deploy to production with monitoring enabled
2. Set up alerts for SSRF attempts
3. Address MEDIUM-002 in future sprint (lower priority)
4. Monitor logs for any unexpected validation failures
**Approval Required From:**
- Security Team: Review SSRF protection implementation
- QA Team: Validate user-facing error messages
- Operations Team: Configure SSRF attempt monitoring