Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the same XSRF protection mechanism found in old GWT-RPC #27

Open
niloc132 opened this issue Jan 9, 2020 · 0 comments
Open

Support the same XSRF protection mechanism found in old GWT-RPC #27

niloc132 opened this issue Jan 9, 2020 · 0 comments
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@niloc132
Copy link
Member

niloc132 commented Jan 9, 2020

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.

@niloc132 niloc132 added enhancement New feature or request good first issue Good for newcomers labels Jan 9, 2020
@niloc132 niloc132 added this to the 1.0 milestone Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant