Identityserver4: X-Frame-Options missing (click-jacking vulnerability in IE) AuthorizeResult

[armitagemderivitec]

Hi,

I am currently in the process of gaining the VerAfied certification by veracode.com for my applications. A dynamic scan has revealed that the X-Frame-Options header is not present in the response from the Authorize Endpoint (IdentityServer4/src/IdentityServer4/Endpoints/Results/AuthorizeResult.cs). This presents a click-jacking vulnerability in some older browsers including IE.

I understand that frame-ancestors covers this vulnerability in most modern browsers but what is the best way of mitigating this vulnerability in IE and should it be built into IdentityServer4 directly?

I tried adding the following in the configure method of the app:

        app.Use(async (context, next) =>
            {
                if (!context.Response.Headers.ContainsKey("X-Frame-Options"))
                {
                    context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
                }

                await next();
            });

and this in my security headers:

            if (!context.HttpContext.Response.Headers.ContainsKey("X-Frame-Options"))
            {
                context.HttpContext.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
            }

but neither get hit when connecting the the aforementioned endpoint. I have temporarily added it to IIS to be added to all responses but I understand that this could have some adverse effects on the javascript client (which I am not using) and session endpoint (which I am using).

Please advise.

Kind regards,

Mike

[TomCJones]

IE is no longer supported by Microsoft. Is it worth trying to fix it?

[armitagemderivitec]

Edge is also vulnerable. Until 'frame-ancestors' are treated correctly on all platforms the threat remains. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors#Browser_compatibility

[armitagemderivitec]

Also worth noting that I'm on version IdentityServer4 version 1.5.2 running on core 1.1.1 in case anything has changed since then but doesn't look like it based on the source code in Github.

[brockallen]

XFO is only needed on HTTP responses that render HTML. Which response from the authorize endpoint are you speaking about? Do you have an example of the full HTTP response on which you'd want the XFO?

[armitagemderivitec]

GET /connect/authorize/login?client_id=....&redirect_uri=...&response_mode=form_post&response_type=code%20id_token...........&x-client-ver=1.0.40306.1554 HTTP/1.1
Host: ....
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Cookie:
......
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Referer: ...../account/login?returnUrl=%2Fconnect%2Fauthorize%2Flogin%3Fclient_id%3D....%26redirect_uri%3Dhttps%253A%252F%252F....%26response_mode%3Dform_post%26response_type%3Dcode%2520id_token%26scope........x-client-ver%3D1.0.40306.1554
Connection: keep-alive
Accept-Encoding: identity
Accept-Language: en-us,en;q=0.5
Content-Length: 0

[armitagemderivitec]

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=UTF-8
Expires: -1
Server: Kestrel
Set-Cookie: .AspNetCore.Identity.Application=....; path=/; secure; httponly
Content-Security-Policy: default-src 'none'; frame-ancestors ....; script-src 'unsafe-inline' 'sha256-VuNUSJ59bpCpw62HM2JG/hCyGiqoPN3NqGvNXQPU+rY=';
X-Content-Security-Policy: default-src 'none'; frame-ancestors ....; script-src 'unsafe-inline' 'sha256-VuNUSJ59bpCpw62HM2JG/hCyGiqoPN3NqGvNXQPU+rY=';
X-Powered-By: ASP.NET
Date: Fri, 24 Nov 2017 12:15:53 GMT
Content-Length: 2201

[armitagemderivitec]

Please see above the request to /connect/authorize/login followed by response where I'd like the X-Frame-Options. Looks like the headers in this response are generated in this file: IdentityServer4/src/IdentityServer4/Endpoints/Results/AuthorizeResult.cs

[brockallen]

And what's an example of how that page is compromised via click jacking?

[armitagemderivitec]

Well given the form is hidden in this case I guess it's impossible but the security engineer at Veracode insists that it must be present. What do you think?

[brockallen]

What do you think?

Well, there was a reason we didn't add it. Also, if an attacker is somehow spoofing this request to authorize in an iframe, the client is protected via the OIDC nonce replay detection. Also, the protocol is designed to allow responses to be returned in an iframe via the prompt=none OIDC param. So for all of these reasons, I don't see a reason to use XFO.

[leastprivilege]

Maybe this security engineer must learn OIDC first ;)

[armitagemderivitec]

Brock/Dominick, thank you so much for your direct input here. I should have looked at this from the OIDC perspective myself. Apologies for wasting your time.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.