Repository navigation
CalDAV connect surfaces verbatim errors to members (LAN scan oracle wider than claimed) #104
Description
What
internal/handler/calendar.go:162-167: ConnectCalDAV failures are written verbatim to the form via h.writeError(w, BadRequest, err.Error()). Connection-refused vs timeout vs TLS-handshake vs auth-failed are distinguishable, so any authenticated non-admin member can use CalDAV connect as a LAN port/service scan oracle.
The caldav-connect-self-service-no-admin-gate claim in audit/claims.yaml accepts the metadata-only SSRF guard as a deliberate trade-off but understates this oracle.
Fix
Return a generic "could not connect" to the caller and log the detail server-side. Then update the claim caveat to describe the remaining exposure honestly.
Related nit found in the same pass: save-time CheckHostnameNotMetadata returns nil on DNS failure (internal/netutil/netutil.go:87-98), so dial-time transport is the only real enforcement. The code comment claiming a save-time DNS blip surfaces as a user-actionable error is inaccurate in that case.
Found by the 0.10.1 pre-release audit (Layer 2, SSRF pass).
Activity
pullfrog commentedon Sep 29, 2026
fix(caldav): generic connect errors, honest oracle caveat (#104)
chore(audit): re-verify claims manifest after 0.10.x changes
shockalotti commentedon Sep 29, 2026
Fixed on main. The connect form returned verbatim transport errors, making failure classes distinguishable; it now returns one generic message and logs the detail server-side. The claims.yaml caveat now describes the residual exposure honestly, including the accepted timing side-channel.