XS-Leak via Leaky Resources on Slack to De-anonymize Users

We discussed this vulnerability during Episode 93 on 25 October 2021

It is possible for a malicious website to associate a visitor with their a known slack account. The attack relies on a difference in behavior when accessing a file with and without permission, and the ability to share a file with specific users. When sharing a file on Slack it’ll be uploaded and when the URL is accessed in a browser it will either redirect away if the user is not authorized to access the file, or it will trigger a download of the file.

This difference in behavior can be detected by a malicious website by noting whether or not a user was redirected. A challenge for exploiting this on slack is that in order to view the file the user must be logged in and send their session cookie in the request, this cookie is protected by SameSite=Lax meaning it is only sent during top-level navigations.

Since an authenticated request will trigger a download and not actually redirect to the page, this lack of redirect can be detected. So an attacker can change the window.location to the URL only the victim can access, wait a period of time, then see if the user is still on the original page. If they are they were not redirected and they are logged in as the victim user.

XS-Leak via form-action CSP Directive

To improve the usefulness of the attack the author looked for a way to make multiple request without requiring the navigation away if they are not the victim user. For this they found a novel XS-Leak vector that works in Chromium-based browsers. This attack works on two points:

  1. The Content-Security-Policy header can be used to specify a form-action directive which will act as an allowlist for HTML Form actions. This will trigger a securitypolicyviolation event if the form-action is not in the allowlist.
  2. Chromium-based browsers will enforce the allowlist through redirects.

With this two points in mind, the attacker can set the target URL in the allowlist, trigger a GET form post to the page (considered a top-level navigation) and if the user is not redirected (download triggered) then they know they have the victim. But if they are redirected, the redirect will trigger a securitypolicyviolation event stopping the navigation, keeping them on the page for further URLs to be attempted.