The following odd behaviour is consistent between Firefox 119 and Chrome 119.
In the context of asp.net core apps, I'm looking to understand the difference between opening a "New Tab" in a browser vs one being opened automagically by the browser to serve an externally clicked link. The effect on a generated asp.net core RequestVerificationToken is not the same.
When a new browser tab is opened manually (and a link pasted), an asp.net core VerificationToken is valid. When a browser tab is opened automagically (to serve a page from an externally clicked link - from an email ect), it is not. Same link. Same page. Same form. The POST will hit a 404 or 401 or whatever the app is set up to do when an invalid VerificationToken is POSTed.
This appears to be true whenever a tab already exists in the browser from the same domain, so I suspect it's to do with cookie leakage between tabs etc - BUT why only when the tab is automatically opened to load a URL vs opening one manually and pasting a link? I would expect consistent behaviour.
The only thing I can even grasp at is that automagically opened tabs seem to result in shorter generated verification tokens. Why would that be the case in only one scenario? What's missing (or extra)?
I added the [IgnoreAntiforgeryToken] attribute to a receiving POST handler and the issue goes away. It really is a result of how the tabs are opened. But WHAT is the result of how they are opened?
UPDATE
I've built a quick test app (stripped down to a single Razor Page) to investigate with. No Authentication, just a simple form with a submit button (and emailed myself a localhost link to launch a tab from). The behavior has flipped. A tab opened remotely works - but it invalidates a tab already loaded in the browser. It feels like it might make more sense this way around - but now I'm even more baffled by the original behaviour. Will update if progress is made ...
The issue you are facing with the
RequestVerificationTokenwith manually opened tabs and tabs opened automatically can be because browser security, session handling, and how web applications manage state and authentication tokens.Modern web browsers implement the same-origin policy to restrict how documents or scripts loaded from one origin can interact with resources from another origin. This policy also influences cookie handling. When you open a link manually in a new tab, the browser treats it as a continuation of your existing session. However, when a link is opened automatically like from an email, the browser might treat it as a potentially less-trusted action and apply stricter security measures, affecting how cookies including session cookies are handled.
The way the browser sends the HTTP referrer header can vary based on how the new tab is opened. Some web applications might use the referrer as part of their security mechanisms. An automatic opening of a link might send a different referrer than manually opening a new tab and pasting the URL.
The generation and validation of anti-forgery tokens can be influenced by the user's session and the browser's security context. When a tab is opened automatically, certain session variables or security contexts might not be transferred in the same way as when a tab is opened manually.
And regarding the observation that automatically opened tabs result in shorter verification tokens is particularly curious. This might indicate a difference in how the token is generated or truncated, possibly due to a difference in the available session or user context information.
You could try checking the browser console logs , check network logs, track session state details when the token is generated and validated to see if there are differences. test in different browser.