DuendeSoftware / Support

Support for Duende Software products
21 stars 0 forks source link

User-agent not available #1441

Closed ym-91 closed 3 weeks ago

ym-91 commented 1 month ago

Which version of Duende IdentityServer are you using? 6.2.3

Which version of .NET are you using? 7.0

Describe the bug

We are currently trying to implement a more powerful firewall, AWS WAFV2, in order to increase security for our business applications. In this context, we have deployed a new set of rules in our UAT environment.

However, one of the rules is blocking our corporate SSO and preventing it from working at all. This is the managed set of rules named "AWSManagedRulesCommonRuleSet", which requires HTTP calls to systematically present a header with a populated User-Agent, which doesn't seem to be the case at least on 2 different routes of our SSO:

  1. /connect/token (method: POST) Accept: application/json Content-Type: application/x-www-form-urlencoded

  2. /.well-known/openid-configuration (method: GET)

Is there a way to force display user-agent on every calls?

I cannot tell for sure that the user-agent's missing behavior is also present on other routes of our corporate SSO.

To Reproduce

Load the routes and look for user-agent on your browser.

Expected behavior

User-agent should be available on every calls.

Log output/exception with stacktrace

Not available.

Additional context

Here is a description of the concerned AWS WAFv2 set of rules: AWSManagedRulesCommonRuleSet: The core rule set (CRS) rule group contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including some of the high risk and commonly occurring vulnerabilities described in OWASP publications such as OWASP Top 10. Consider using this rule group for any AWS WAF use case.

Architecture: Our Corporate SSO based on Duende is deployed through AWS ECS Service (Docker container) and is behind an application load balancer.

RolandGuijt commented 1 month ago

Are you using server-side clients? Then the requests to the endpoints you mention are probably back-channel requests. They are not initiated by a browser but by the server application hence the absence of the user-agent header. Is there a way to make an exception to the rule?

RolandGuijt commented 1 month ago

@ym-91 Would you like to follow up? If not I'd like to close this issue.

ym-91 commented 1 month ago

Hi Roland, Thanks for your reply. I'll take a look to our server application configuration and let you know asap.

ym-91 commented 1 month ago

We enabled the ForwardedHeaders option in the configuration of the application server (XForwardedFor, XForwardedProto and XForwardedHost) and it seems to work now. You can close this issue. Thanks for your help!