Why do all ASP.NET MVC websites allow and ignore the string "/(F())/" in front of ANY URL?

Question

I noticed that requests to my ASP.NET web app succeed even if I prefix the URL with /(F())/ which is nonsense. The usual action method is hit. Request.Url does not show the URL prefix. So if I request /(F())/x the action sees Request.Url == "/x"

I then tried other ASP.NET MVC sites such as Stack Overflow:

https://stackoverflow.com/(F())/questions/43593952/why-do-all-asp-net-mvc-websites-allow-and-ignore-the-string-f-in-front-o

According to Fiddler the request is being made as intended:

As you can see the request URL is correct and the server replies without redirect with the full content. The browser window shows that URL as well.

This URL does work. So I conclude that something in the framework causes this request to be rewritten and the prefix dropped. It looks like the Stack Overflow application was unaware of the prefix.

The same result occurs in a fresh MVC app created in Visual Studio 2017 on .NET 4.6.2 on Windows 7.

Another funny victim: https://www.microsoft.com/(F(blah))/en-us/default.aspx (The Microsoft homepage).

The string (F()) is not special. See the comments for other strings that work e.g. /(F(pV0)).

Since my ASP.NET code is blind to the original URL (Request.Url does not contain the prefix) I seemingly cannot even detect this condition and fail the request.

I have not confirmed that this is an MVC problem. It seems hard to find the culprit in the huge sea of functionality that ASP.NET+IIS ship with. Who knows what features are turned on by default?! I don't think anyone really knows :)

At the very least this is an SEO problem but I find it disturbing as well to not know what's going on. That's why I'm investigating. What behavior is that and how to get rid of it?

Answer 1

This is caused by the ASP.NET cookieless feature set. The URL may now look like this:

http://example.com/MyWebApplication/(A(XXXX)S(XXXX)F(XXXX))/home.aspx

Breaking it down:

• A(XXXX): This is the Anonymous-ID. It is used to identify the (anonymous) user accessing your application. The string may or may-not be encrypted, depending on your configuration settings in the section.
• S(XXXX): This is the Session-ID (same as V1.1).
• F(XXXX): This is the Forms Authentication ticket.

Since cookieless mode is entirely obsolete, causes SEO problems and confusion I recommend to disable all possible cookieless features on all ASP.NET websites immediately.

For each of the above features (Forms Authentication, Anonymous Identification, and Session State), you can control if and when the cookiesless feature will be used, and when the cookieless feature will be used instead. The configuration setting controlling this is: cookieless="UseCookies | UseUri | UseDeviceProfile | AutoDetect"

In my case I set:

<anonymousIdentification enabled="false" />
<sessionState ... cookieless="UseCookies" />

You will need to adapt this to your needs.

This hopefully addresses the generation of these URLs but seemingly it does not prevent the framework from (silently) accepting such a URL. The documentation claims that a header AspFilterSessionId will be present but I found that not to be the case.

For now I have no solution for blocking requests to these unwanted URLs.