CSRF challenge fails after Chrome cookie security update [🐛]

[bkimminich]

(index):43 Uncaught DOMException: Blocked a frame with origin "http://htmledit.squarefree.com" from accessing a cross-origin frame.
    at update (http://htmledit.squarefree.com/:43:24)

This error message is expected. The Juice Shops explicitly sets the header X-Frame-Options: SAMEORIGIN in the response, which is probably causing this behavior. The result is, that the content of the profile page is not getting displayed in the lower frame of the HTML editor. This does however not prevent the application from receiving and evaluating the request parameters, so the CSRF attack still works.

I have seen the HTML editor being used in demos of pentest findings and being mentioned in published books, so I am rather confident in its stability and that our use case won't bother its owner. After all, its a very simple static website.

While reproducing the error message in Chrome, I stumbled however across this message:

This is generally good news, but problematic for the CSRF challenge and a possible CORS challenge, as Chrome is right now in the process of changing the way cookies are sent in cross-origin requests (see for example https://www.chromestatus.com/feature/5088147346030592). As Google is rolling this out gradually, the default for this setting will vary across different Chrome installations during the rollout period. This development was unfortunately completely unnoticed by me until now.

Options as far as I know:

• Tell users that the challenge needs to be done with Firefox. But Mozilla will soon follow Google, so the issue will only be postponed a bit (see https://bugzilla.mozilla.org/show_bug.cgi?id=1604212).
• Set the flags SameSite=None and Secure in the session cookie. Especially the latter is however not generally possible, as Juice Shop is usually accessed without TLS. This in turn could be approached by disabling certain challenges when no TLS is used (similar to disabling unsafe challenges on Docker). Are there any thoughts on allowing Juice Shop to be run with runtime-generated self-signed certificates?
• Redesign the challenge in such a way that that it targets a new or existing feature in Juice Shop, which does not require a user session but still results in persistent data changes. It is probably not easy to find an interesting example that is not too contrived.

So for the short-term I only see the option to pull the CSRF challenge out of the development branch. I will probably experiment a bit with other approaches, but this will take some time.

(see also #1322 / #902)

[ebell451]

Do what most pentesters should/would do in this situation and use an older version of the browser. Developers should not rely on the end-user nor malicious attacker being on the latest version of browsers.

[bkimminich]

You're right, anyone could still solve it as long they a browser that is old enough... it only "fails" in the automated test suite because there the latest Chrome is used.

[github-actions]

This thread has been automatically locked because it has not had recent activity after it was closed. 🔒 Please open a new issue for regressions or related bugs.