.NET: Improve proxy target validation in DevUI aggregator

[SergeyMenshykh]

Adds validation of the resolved proxy target in the DevUI aggregator so forwarded requests stay on the configured backend. Includes unit tests covering the proxy routing behavior.

[Copilot]

Pull request overview

This PR tightens the DevUI aggregator’s proxying logic by validating that the resolved proxy target URI remains on the configured backend (scheme/host/port), preventing unintended redirection when combining backendUrl with a request path. It also expands the DevUI aggregator unit tests with an in-process stub backend to observe forwarded requests.

Changes:

• Add proxy-target URI validation in DevUIAggregatorHostedService.ProxyRequestAsync and return 400 for invalid targets.
• Add new unit tests that spin up a stub backend + aggregator and assert forwarded request path/query behavior for /v1/conversations and /devui.
• Add helper infrastructure in the test suite to host the stub backend and configure a single-backend DevUI resource.

Reviewed changes

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

File	Description
dotnet/src/Aspire.Hosting.AgentFramework.DevUI/DevUIAggregatorHostedService.cs	Adds proxy target URI validation (scheme/host/port) before forwarding requests.
dotnet/tests/Aspire.Hosting.AgentFramework.DevUI.UnitTests/DevUIAggregatorHostedServiceTests.cs	Adds proxy routing tests and helper hosting context for backend/aggregator verification.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 78%

✓ Correctness

The PR adds a ValidateProxyTarget helper that constructs the proxy target URI and verifies the resulting host, scheme, and port still match the configured backend. The implementation is correct and provides defense-in-depth against open-redirect attacks via path manipulation. All calers construct the path parameter with known prefixes (e.g., /v1/conversations/, /devui/), so the validation will pass for legitimate requests and reject crafted inputs like protocol-relative paths (//evil.com/...). The test coverage exercises the happy path and normalized traversal paths. No correctness issues found.

✓ Security Reliability

The PR adds a well-implemented ValidateProxyTarget method that checks host, scheme, and port after URI resolution to prevent SSRF. The validation correctly handles path traversal, absolute URI injection, and protocol-relative paths (//host). All existing call sites already prefix user-controlled segments with known paths, making this a sound defense-in-depth measure. No security or reliability issues found.

✓ Test Coverage

The PR adds proxy target validation (ValidateProxyTarget) that returns 400 Bad Request when a crafted path would redirect to an unintended host. The test suite covers three happy-path scenarios (conversation route, devui route, path normalization with ..), but critically lacks any test exercising the rejection path — i.e., a request that would cause ValidateProxyTarget to return null and the handler to return 400. For a security-focused validation PR, testing that malicious inputs are actually blocked is the most important coverage to have.

✓ Failure Modes

The proxy target validation logic in ValidateProxyTarget is correct and properly guards against host/scheme/port redirection. The code integrates cleanly at the single ProxyRequestAsync entry point. No concrete silent-failure paths or operational failure modes were found in the changed code.

✓ Design Approach

I did not find a design-approach issue that clears the required evidence bar. The new validation sits on the shared proxy path, and the changed tests align with the existing routing contract for conversation and DevUI forwarding without contradicting any documented invariant I could verify in the nearby code.

---

Automated review by SergeyMenshykh's agents

[SergeyMenshykh]

@copilot resolve the merge conflicts in this pull request