Debugging a Race Condition Between Microsoft Edge and SharePoint
A random redirect when opening Edge leads to an investigation discovering some interesting behavior between Edge and SharePoint.
Introduction
I recently debugged an issue at work that I thought was worthy of a blog post. It yields some insight into how Edge and SharePoint operate, as well as a useful trick to trace network traffic for chromium based browsers as well as electron.js apps when external proxies don’t work well.
Since it’s work related I have opted to not include any screenshots or sensitive information, hopefully you can follow my word soup without a visual aid…
Problem Info
A user was using the default Edge browser and had their homepage set to a SharePoint site. Upon launching Microsoft Edge, the user would be taken to their O365 login screen, and after login they would be redirectetd to a random SharePoint site; more accurately, the user would be redirected to the logo of a random SharePoint site. Clearing cache sometimes fixes the issue - more often, it doesn’t.
Problem Analysis
Capturing Network Traffic
The first thing I did was open up the Network tab in the debugging tools and save the network traffic as I wanted to see the redirects. However, this didn’t capture the initial network traffic that the browser initiates on launch. In essense, we would launch Edge, a bunch of redirects would route from sharepoint > ms online login, at which point I was finally able to open the developer console and capture traffic. This was too late. I needed to see all network traffic upon Edge startup.
I tried my usual external proxy tools to capture network traffic. Issues would arise as the user was not an administrator on their machine and could not install a certificate to decrypt traffic, or the proxy would ruin the authentication as we have Windows Integrated Authentication (WIA) enabled in our environment.
In the end, I found a nifty post showing I can start Edge with some parameters to dump network traffic to a log file:
msedge.exe --log-net-log=%USERPROFILE%\Desktop\ReproNetlog.json --net-log-capture-mode=Everything
This also works with electron.js apps and chromium based browsers! Super handy!
From here, we logged in and reproduced the issue. A ReproNetlog.json file would be created with the network traffic since msedge.exe was launched. Reading the output can be done in Fiddler using the FiddlerImportNetlog extension.
Traffic Analysis
Upon analyzing the traffic, I see a few more redirects than expected.
It goes something like this:
- Launch Edge
- Go to sharepoint.com
- sharepoint.com redirects to sharepoint.com/_forms/default.aspx
- default.aspx redirects you to login.microsoft.com and sets a cookie (RpsContextCookie) of the SharePoint site you were trying to go to
- [user enters credentials] login to login.microsoft.com
- redirects you back to default.aspx
- POST request to default.aspx redirects you to the SharePoint page you were originally navigating to (step 2) based on the cookie that was set at step 4 (cookie: RpsContextCookie)
Step 5 is manual, however, before step 5 all the redirects are done immediately upon Edge startup.
The interesting thing is that there was quite a bit of network traffic peppered in between steps 1-5. Some of which were querying other SharePoint sites and pulling their logos.
I also noticed a few calls to domains I didn’t recognize.
ntp: New Tab Page
One of the interesting locations was an address:
https://ntp.msn.com/edge/ntp
When researching, I came across this interesting post xss New Tab Page which shows a previous vulnerability in the service; more importantly, it provides some insight into what it is and what it’s doing.
Ultimately, when you open a new tab in Edge you’ll be presented with a dynamic page with content that is relavent to you:
The important note is that this content is dynamic and pulls from Microsoft’s servers. There are quick links at the top and if logged into Edge with your work profile, more sections will show up such as recent/frequent SharePoint sites.
The last critical piece of the puzzle is that Edge has a setting to pre-load the new tab page for performance reasons, and this is enabled by default.
Root Cause
So, I now know that there are a series of redirects when logging in, and that a cookie is used after logging into login.microsoft.com to redirect you to the SharePoint site you originally requested.
I also know that Edge’s new tab page by default pulls from Microsoft servers so it is unaffected by cookies/cache, and this page is pre-loaded on startup.
I can now deduce that the phases in the login flow looks something like this:
- User opens Edge, a series of redirects takes place to get them to login.microsoft.com. The
RpsContextCookieis set. (user starts entering credentials) - In parallel to the user entering credentials, Edge is pre-loading the new tab page, which is querying the recent/frequent SharePoint urls for their logos to display in the new tab page. These queries to SharePoint CORRUPT the
RpsContextCookiecookie as they also set it’s value. - (The user finishes entering credentials and logs in) login.microsoft.com redirects back to sharepoint.com/_forms/Default.aspx where the corrupted
RpsContextCookieis used to redirect the user to the logo of the last SharePoint site that was fetched in phase 2.
The result is the user being redirected randomly on login. Clearing cache may or may not fix the issue temporarily.
Resolution
For the user, we just disabled pre-load in the Edge settings and it seemed to work.
This can be applied globally as a GPO to the enterprise if it is a more widespread issue (e.x. if your default enterprise homepage is a SharePoint site).
Additionally, there are more GPO settings such that you can disable web fetching on the new tab page or set the page to a local, offline page chrome-search://local-ntp/local-ntp.html.
Conclusion
This was an interesting race condition to debug and I learned quite a bit about the behavior of Edge/SharePoint, as well as a neat trick to capture network traffic of any chromium/electron.js based application at startup. I hope the reader has found something useful from this article as well.