Starts off by detailing a self XSS through JupyterLabs Notebook’s /lab endpoint, where an attacker can control the page contents. In and of itself this isn’t an issue, an attacker can only control the page contents of a notebook instance they own. It gets more interesting though when you throw cookies into the mix and how they’re used on the AWS endpoint. All JupyterLabs Notebook instances run on the sagemaker.aws subdomain, and one of the cookies used is the _xsrf, which is a CSRF token. An attacker can use their code on their own notebook instance to set the _xsrf cookie that applies to the entirety of the sagemaker.aws subdomain on a victim’s browser.

This can be used to perform CSRF and open a terminal to the victim’s JupyterLab instance via a cross-origin websocket, since the origin header isn’t checked. While the post points out that in theory, the samesite attribute defaulting to “Lax” on most browsers should have prevented this attack, they mention Chrome has a “2 minute grace period” where cookies that have been set without a samesite attribute can be sent on cross-site requests for two minutes afterwards. This “Lax + POST” support is set to be removed in the future, but currently it’s taken advantage of for this attack.