You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After PR #1228 (closes #1143, SEC-03) landed, 3 of the 8 Azure NewClientWithHTTP constructors (savingsplans, synapse, managedredis) defensively fall back to httpclient.New() when the injected httpClient is nil. The other 5 -- database, cache, search, cosmosdb, compute -- blindly assign httpClient to the struct field with no nil check:
If a test (or a future production caller) ever passes nil, these clients will nil-pointer-panic on the first c.httpClient.Do(req) call rather than serving requests through the SSRF-hardened transport.
Defensive consistency: nil-fallback to httpclient.New() is the established cross-cutting pattern memory feedback_azure_use_httpclient_new.md is built around. Lining all 8 up on the same shape reduces the surface where a future caller can stumble.
Latent SSRF re-introduction risk: if someone copy-pastes the existing 5 constructors as a template for a new Azure service and adds an if httpClient == nil { httpClient = http.DefaultClient } (matching net/http Go idiom for nil-safety), they re-introduce SEC-03. The 3 hardened constructors are a safer copy template.
Suggested change
Add the same if httpClient == nil { httpClient = httpclient.New() } guard at the top of NewClientWithHTTP in each of the 5 sibling constructors:
providers/azure/services/database/client.go
providers/azure/services/cache/client.go
providers/azure/services/search/client.go
providers/azure/services/cosmosdb/client.go
providers/azure/services/compute/client.go
Plus a regression test in each package mirroring TestNewClientWithHTTP_NilFallbackIsHardened from synapse/client_test.go / savingsplans/client_test.go / managedredis/client_test.go.
Out of scope
Existing CR findings or other security work on these clients.
Problem
After PR #1228 (closes #1143, SEC-03) landed, 3 of the 8 Azure
NewClientWithHTTPconstructors (savingsplans,synapse,managedredis) defensively fall back tohttpclient.New()when the injectedhttpClientis nil. The other 5 --database,cache,search,cosmosdb,compute-- blindly assignhttpClientto the struct field with no nil check:If a test (or a future production caller) ever passes nil, these clients will nil-pointer-panic on the first
c.httpClient.Do(req)call rather than serving requests through the SSRF-hardened transport.Why this matters
httpclient.New()is the established cross-cutting pattern memoryfeedback_azure_use_httpclient_new.mdis built around. Lining all 8 up on the same shape reduces the surface where a future caller can stumble.if httpClient == nil { httpClient = http.DefaultClient }(matchingnet/httpGo idiom for nil-safety), they re-introduce SEC-03. The 3 hardened constructors are a safer copy template.Suggested change
Add the same
if httpClient == nil { httpClient = httpclient.New() }guard at the top ofNewClientWithHTTPin each of the 5 sibling constructors:providers/azure/services/database/client.goproviders/azure/services/cache/client.goproviders/azure/services/search/client.goproviders/azure/services/cosmosdb/client.goproviders/azure/services/compute/client.goPlus a regression test in each package mirroring
TestNewClientWithHTTP_NilFallbackIsHardenedfromsynapse/client_test.go/savingsplans/client_test.go/managedredis/client_test.go.Out of scope
Existing CR findings or other security work on these clients.
Triage
type/chorepriority/p3severity/lowurgency/eventuallyimpact/internaleffort/xstriaged