Applications written ASP.NET can take advantage of the antiforgery middleware to prevent Cross Site Request Forgery attacks. When properly used, this middleware requires requests to include both a cookie and parameter value which must validate together (along with the user’s session) before the request will be processed.

By default, the cookie and parameter name (i.e. AntiforgeryTokenFieldName) is __RequestVerificaitonToken, however this can be changed in the configuration.

When testing ASP.NET application with antiforgery enabled, it is not uncommon to observe cookies with a name like __RequestVerificaitonToken_L2hlbHBkZXNr0. A brief review of the relevant code

(https://github.com/aspnet/AspNetWebStack/blob/749384689e027a2fcd29eb79a9137b94cea611a8/src/ System.Web.WebPages/Helpers/AntiForgeryConfig.cs#L135) reveals that the additional section of the name is an encoded representation of the virtual application path (appPath), which is included when the appPath is not empty or /. There is a comment with this functionality indicating that it is intended to ensure unique cookie names to prevent a development server cookie and IIS cookie stomping on each other when they both run on localhost.

The appPath is encoded using HttpServerUtility.UrlTokenEncode, examining this function (https://referencesource.microsoft.com/#System.Web/Util/HttpEncoder.cs,856) reveals that the a non-standard variation of URL Safe Base64 encoding is used. This implementation first uses standard base64 encoding, then removes the padding characters (=) and replaces them with an integer representing how many padding characters were removed, then replaces + with – and / with _.

Note, we have observed instances in the wild which do not include the integer representing the padding required.

It is therefore possible to implement a utility to extract the decoded appPath from the cookie name. AppCheck has made this utility available under an MIT licence, it is available here.
On its own, knowledge of the virtual application path is of limited use and may also form the first part of the URL depending on the environment. However, in some cases it may help to inform or target further attacks against the application.

Currently this behaviour cannot be disabled or overridden. If disclosure of the application path is a significant risk to your application, consider creating an alternative implementation for AntiForgery tokens and calling this rather than the built in helper.

Check out this utility, that expects a cookie name and returns the decoded virtual application path.

How can AppCheck Help?

AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principle to detect vulnerabilities – including this one – in in-house application code. AppCheck also draws on checks for known infrastructure vulnerabilities in vendor devices and code from a large database of known and published CVEs. The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.

About AppCheck

AppCheck is a software security vendor based in the UK, that offers a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure.
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com