Validating Sec-Fetch headers

[rasander]

Hello.

This is not a bug report, nor really a feature question, but more like a question/topic for discussion.

Have you considered adding option for validating Sec-Fetch request headers for the authorize endpoint?

This may add an extra layer of control for eg. avoiding external sites (or eg bookmarks or search engines) to deeplink to my authorize endpoint. While a malicous site cannot use the authorize for anything (because the whitelisted RedirectUri's is not in their control), it can be a part of tricking the end user of thinking the malicous site is related to my service because they link to my login page.

There might be other/better purposes too.

Ref: https://web.dev/articles/fetch-metadata

[khalidabuhakmeh]

@rasander This is a very cool specification, and it seems to add some additional security and scrutiny to incoming requests. At first glance, it makes more sense that it should be built into ASP.NET Core, similar to the CORS functionality.

I could imagine the codebase looking something like this.

builder.Services.Configure<SecFetchOptions>(options =>
{
    // a global handler for the SecFetchMiddleware
    options.DefaultHandler = (ctx) =>
    {
        var options = ctx.Options;
        if (ctx.Request.Dest == "image") {
            return SecFetchResult.Allow;
        }
        return SecFetchResult.Deny;
    };
});

app.UseSecFetch();
app.MapGet("/", () => "Hello World!")
    .WithSecFetch(new(site: "self", dest: "image", mode: "navigate-to"));

This might make a fun side-project for folks needing this kind of scrutiny. It's likely out of scope for IdentityServer, but what do you think?

[khalidabuhakmeh]

@rasander Oh, also, you mentioned a potential attack that this would mitigate. Do you have a Proof of Concept or example of this being something users may be susceptible to?

[rasander]

@khalidabuhakmeh: I havent digged much into this yet. For testing I created a middleware - loaded before IdentityServer - that handles some simple validaton cases (for both the /connect endpoints, and our own webflow endpoints), but I need to to more testing. I may share my findings later.