icesfont

Despite the session cookie being SameSite=Strict, we can still CSRF a request to set the memo to contain an XSS payload, and the corresponding session cookie will be set (as part of a response to a top-level navigation). We can also stop the cookie from being overridden by cancelling the redirect to / (via hitting the redirect limit). The remaining part of the challenge is to actually send this cookie with a navigation request.

When the headless bot navigates to a page with page.goto(), the initiator is null, which is treated as same-site with the request URL. Adjacently, when a request is made in Chromium, if the initiator site and target site agree according to this prior check, then [SameSite=Strict cookies will be sent regardless of whether the chain of redirects to the target site included a cross-site redirect or not, by default](https://source.chromium.o

icesfont

/user/:id uses res.send, which sends an ETag header with responses with status code 200. Firefox will send a conditional request the second time round when requesting /user/:id twice, and Express will respond with a 304.

When dealing with a 304 response, if a new CSP header is set on the response, it overrides the previous one (this is on purpose -- see w3c/webappsec-csp#161). However, in Firefox, the cached Content-Type is used, so you can get the more permissive script-src 'self' CSP by switching from public to private before the 2nd request is made. The response will have Content-Type: text/plain, but it'll use the cached Content-Type: text/html instead.

Write your payload on another page to bypass the CSP.