CSRF protection

[mattbasta]

Looking at the source and our deployed instance of adminjs, it doesn't look like it has CSRF protection. Someone with knowledge of an installation of adminjs could trigger destructive actions for logged-in users from a separate website simply by getting the logged-in user to click a link.

Are there plans to add CSRF protection to adminjs? If this is not currently planned, would contributions adding this be welcome?

[dziraf]

This should be resolved now since GET requests don't trigger mutating behaviours anymore.

[mattbasta]

Hey @dziraf, thanks for giving this consideration.

Unfortunately CSRF is important for all request types, not just GET. Consider this: if I know the URL of an adminjs instance (e.g., from certificate transparency logs), the URL of the endpoint to delete a user could probably be guessed. I could create a page with a form that automatically issues a POST (that is, literally submitting the <form>) to that URL. If I got a logged in user to visit my page, it would immediately trigger a deletion (by way of redirection). This can even be accomplished via email.

CSRF avoids this by requiring a unique string (either signed or stored) in the body of each request that's tied to the logged in user. If CSRF was present in the scenario above, the POST would fail because the bad actor couldn't have added a CSRF token unique to the user they got to visit the page.

[dziraf]

@mattbasta I'll see if we can implement CSRF protection without making breaking changes in our packages since v8 is still far away.

[mattbasta]

A common approach is to add http headers to XHRs, which is easy to do with something like a js API. However anyone making their own requests, or anyone with a custom form based login would be out of luck. This change would almost certainly require a major version bump.