Feat: Add session-aware HTTP client to Config

[Chocapikk]

Summary

Adds a session-aware HTTP client directly in the protocol package that reduces boilerplate for exploits dealing with authentication, cookies, and multiple sequential requests, and folds the existing HTTPSendAndRecv* helpers onto the same engine so there is a single HTTP API surface.

protocol.NewGeneric(conf.GenerateURL) returns a persistent client that manages cookies automatically, injects auth headers when SetBasicAuth() is used, and resolves paths via the provided generateURL function.

The client is fully decoupled from Config - it takes a generateURL func(string) string instead of a *Config reference, so it's reusable without pulling in the config layer.

Real-world example

Here's a before/after from a real exploit (openDCIM SQLi-to-RCE chain, CVE-2026-28515):

Before - manual auth headers and request boilerplate:

func authHeaders(conf *config.Config) map[string]string {
    user := conf.GetStringFlag("username")
    pass := conf.GetStringFlag("password")
    if user == "" && pass == "" {
        return map[string]string{}
    }
    return map[string]string{"Authorization": protocol.BasicAuth(user, pass)}
}

func postForm(conf *config.Config, form map[string]string) bool {
    body := protocol.CreateRequestParamsEncoded(form)
    client, req, ok := protocol.CreateRequest("POST", conf.GenerateURL(installPath), body, false)
    if !ok {
        return false
    }
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
    protocol.SetRequestHeaders(req, authHeaders(conf))
    resp, _, ok := protocol.DoRequest(client, req)
    if !ok {
        return false
    }
    return resp.StatusCode == http.StatusOK || resp.StatusCode == http.StatusFound
}

After - same exploit chain with the new protocol.Client:

h := protocol.NewGeneric(conf.GenerateURL)
h.SetBasicAuth(user, pass)

func injectSQL(h *protocol.Client, field, sql string) bool {
    resp, _, ok := h.PostFormEncoded(installPath, buildForm(field, sqliPrefix+sql+sqliSuffix), protocol.WithoutRedirect())
    if !ok || resp == nil {
        return false
    }
    return resp.StatusCode == http.StatusOK || resp.StatusCode == http.StatusFound
}

What's included

• Cookie jar by default - cookies persist across requests automatically
• Auth helpers - SetBasicAuth() / SetHeader() credentials included in every request
• Functional options - WithoutCookies(), WithoutRedirect(), WithTimeout(), WithHeaders(), WithContentType(), FireAndForget()
• Content-Type helpers - PostJSON, PostForm, PostFormEncoded, PostMultipart
• Base path prefix - SetBasePath("/api/v1") to avoid repeating common prefixes
• Fire and forget - for payloads where the server never responds
• Custom client support - NewCustom() for when you need a non-default http.Client

Single HTTP API

To avoid having two parallel HTTP APIs, the legacy HTTPSendAndRecv* helpers and HTTPGetCache have been rewritten as thin wrappers that delegate to the new Client. Each wrapper still takes the same arguments, returns the same (*http.Response, string, bool) tuple, and behaves the same way externally — only the implementation has been collapsed onto the new engine.

For example:

func HTTPSendAndRecvWithHeaders(verb, url, payload string, headers map[string]string) (*http.Response, string, bool) {
    return newLegacyClient().Do(verb, url, payload, WithHeaders(headers))
}

This keeps every existing exploit working untouched while removing the duplicated request-building code.

Compatibility

Public signatures of HTTPSendAndRecv, HTTPSendAndRecvNoRedirect, HTTPSendAndRecvURLEncoded, HTTPSendAndRecvURLEncodedParams, HTTPSendAndRecvURLEncodedAndHeaders, HTTPSendAndRecvURLEncodedParamsAndHeaders, HTTPSendAndRecvWithHeaders, HTTPSendAndRecvWithHeadersNoRedirect, and HTTPGetCache are preserved. Behavior is preserved (each wrapper builds a one-shot Client so the old stateless semantics are kept). cacheResponse is private and was tweaked to take a URL string rather than a *http.Request, since the wrapper no longer owns the request directly.

CreateRequest, DoRequest, SetRequestHeaders, BasicAuth, CreateRequestParams, CreateRequestParamsEncoded, ParseCookies, CookieString, GetSetCookieValue, MultipartCreateForm, MultipartAddField, MultipartAddPart, MultipartAddFile, and DoRawHTTPRequest are unchanged and still public.

Test plan

• go build ./...
• go vet ./...
• golangci-lint run ./... — no new findings introduced by this PR
• go test ./protocol/ -v — 21 tests covering cookie persistence, auth injection, header merging, timeout, fire-and-forget, multipart upload, base path, and functional options
• go test ./... — all project tests pass

[terrorbyte]

First off, thanks for the contributions and at first glance these all look really excellent! I'll get the team on reviewing them all and should get back to you with reviews pretty quick, with maybe the exception of this one as it's something we've long talked about on the VulnCheck side and there might be a some restructuring around the HTTP handling that is necessary (as I see you have caught on). So this one might have a bit more back and forth as we figure out what the best API strategy is :)

Thanks again for contributing!

[Chocapikk]

First off, thanks for the contributions and at first glance these all look really excellent! I'll get the team on reviewing them all and should get back to you with reviews pretty quick, with maybe the exception of this one as it's something we've long talked about on the VulnCheck side and there might be a some restructuring around the HTTP handling that is necessary (as I see you have caught on). So this one might have a bit more back and forth as we figure out what the best API strategy is :)

Thanks again for contributing!

Thanks! Totally understand, this touches core architecture and there's a real choice between patching on top or rethinking the HTTP layer. Happy to adapt this PR to whatever direction the team decides, or hold off until the new design is clearer. Just let me know what's most useful.

[Copilot]

Pull request overview

Adds a new session-aware config.HTTPClient that hangs off Config to simplify exploit HTTP flows (persistent cookies, optional auth injection, URL generation, and convenience helpers), along with a comprehensive config package test suite for the new client.

Changes:

• Introduce Config.HTTP() which lazily constructs a persistent HTTP client with cookie-jar support, redirect control, per-request functional options, and helper methods (JSON/form/multipart).
• Add Config.AddHTTPAuth() and new Config fields to support opt-in HTTP Basic Auth header injection.
• Add config/http_test.go covering cookie persistence, auth injection, headers, timeouts, redirect behavior, multipart, base path, and fire-and-forget behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
config/http.go	Implements the new session-aware HTTP client, request options, and helper methods.
config/http_test.go	Adds tests for the new HTTP client behaviors and functional options.
config/config.go	Extends Config with optional HTTP Basic Auth support and the lazy HTTPClient handle.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

conf.HTTP() refreshes the Authorization header when creds are present, but never clears it when credentials are later emptied (or when auth is disabled). This can leave a stale Authorization header being sent unexpectedly. Consider explicitly deleting the header when httpAuthEnabled is false or when both username/password are empty.

Suggested change

	// Refresh auth header each time in case credentials changed.
	if conf.httpAuthEnabled && (conf.Username != "" || conf.Password != "") {
	conf.httpClient.headers["Authorization"] = protocol.BasicAuth(conf.Username, conf.Password)
	// Refresh auth header each time in case credentials changed, and clear it when disabled.
	if conf.httpAuthEnabled && (conf.Username != "" || conf.Password != "") {
	conf.httpClient.headers["Authorization"] = protocol.BasicAuth(conf.Username, conf.Password)
	} else {
	delete(conf.httpClient.headers, "Authorization")

[Copilot]

In FireAndForget mode, doRequest ignores the error from client.Do(req) and always returns ok=true. This makes it impossible for callers to distinguish a successfully-dispatched request from cases like connection/DNS failures (and also drops any helpful logging). Either propagate the error (return ok=false) or document/rename the option to make it clear errors are intentionally suppressed, and consider logging the error at least at debug level.

[Copilot]

resolvePath concatenates basePath + path directly, which can produce malformed paths when callers pass a path without a leading slash (e.g. basePath "/api" + "users" => "/apiusers"). Using protocol.BuildURI(h.basePath, path) (or otherwise normalizing slashes) would make SetBasePath more robust and consistent with existing URL-building helpers.

Suggested change

	return h.basePath + path
	return protocol.BuildURI(h.basePath, path)

[Copilot]

Several tests share variables with the httptest handler goroutine (e.g. received here) without synchronization. This is a data race under go test -race and can be avoided by sending observed values back over a channel, using sync/atomic, or guarding with a mutex.

[Copilot]

Calling t.Fatalf (or t.Fatal) from inside the httptest server handler goroutine can lead to confusing failures and, in some cases, hangs/timeouts if the handler exits before writing a response. Prefer capturing the error in the handler (e.g., send it over a channel) and failing the test from the main test goroutine.

[spac3yspace]

Hey @Chocapikk, thanks for you PR, this is really great! I like these additions so far, and the only substantial change I'd request be made is decoupling the new httpclient from the existing Config struct. Not every exploit will need an associated http client, so I think separating this into its own package would work better. Maybe protocol/httpclient?

[spac3yspace]

Could we have two initializers? I think this would work great for creating a generic client, but It'd be really nice if we could also have one users can customize for better control of client & transport options. I was thinking something like ClientGeneric() and ClientCustom().

[Chocapikk]

Thanks for the review! I've addressed all the feedback.

The HTTP client is now fully decoupled from Config into its own protocol/httpclient package. It takes a generateURL function instead of a *Config reference, so it's reusable without pulling in the config layer. Constructors, options, cookie management, and all HTTP methods are self-contained there.

Let me know if anything else needs adjusting

[spac3yspace]

No further comments from me. These changes are great, thanks!

[j-baines]

I think flagging the old functions as deprecated goes too far. It would break out internal linting for one, but I think it would also require a major version bump.

[vlobstein-vc]

I think flagging the old functions as deprecated goes too far. It would break out internal linting for one, but I think it would also require a major version bump.

Already reverted in 3e970c0, no Deprecated: tags left in the diff. Two ways to land the rest and both commits are on the branch:

• Keep 7cb1144 : old HTTPSendAndRecv* helpers forward through the new Client engine. Same public API, single HTTP code path.
• Drop 7cb1144 : old helpers keep their original bodies untouched. New Client lives alongside.

Which one do you want?