You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The XHR wiring already sets a custom header, so modern browsers should already be safe, with the exception of cases where flash is installed and can be convinced to make a bad cross-origin call - as far as we can tell, this is the main remaining issue to mitigate. Flash is apparently scheduled to die in late 2020, so if this is indeed the only issue remaining, the mitigation will not need to be long-lived.
The main solution we're looking at is to have the server specify a per-session cookie (readable only by the application, not by attackers), and the value of this cookie must be put in a header on the XHR. This cookie naturally cannot be set to be HttpOnly (as session ID cookies generally should be). Rather than rotate the cookie per request, we're suggesting just setting the cookie once, to be unique for that user's session.
As in the previous impl, this will come with a default impl, which is easy to opt-in to, but also allow it to be pluggable. A structure has been suggested where the RemoteServiceFactory allows either an optional arg of a lambda to finish creating the XHR, or some kind of builder pattern where such a lambda could be specified.
The text was updated successfully, but these errors were encountered:
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html discusses the issue and potential mitigation options. The main idea is to verify that the client request actually came from the real application rather than being requested in some other way by the client's own browser in a malicious way.
The XHR wiring already sets a custom header, so modern browsers should already be safe, with the exception of cases where flash is installed and can be convinced to make a bad cross-origin call - as far as we can tell, this is the main remaining issue to mitigate. Flash is apparently scheduled to die in late 2020, so if this is indeed the only issue remaining, the mitigation will not need to be long-lived.
The main solution we're looking at is to have the server specify a per-session cookie (readable only by the application, not by attackers), and the value of this cookie must be put in a header on the XHR. This cookie naturally cannot be set to be HttpOnly (as session ID cookies generally should be). Rather than rotate the cookie per request, we're suggesting just setting the cookie once, to be unique for that user's session.
As in the previous impl, this will come with a default impl, which is easy to opt-in to, but also allow it to be pluggable. A structure has been suggested where the RemoteServiceFactory allows either an optional arg of a lambda to finish creating the XHR, or some kind of builder pattern where such a lambda could be specified.
The text was updated successfully, but these errors were encountered: