I'm working on a project that requires to have a signup/login functionality exposed to partners who manage their own website. For some of these websites they reuse our own backend, and just change the css styling, but other are completely standalone: for this reason it has been thought to prepare a static login form that would be given to the partners, which would trigger a POST request to our own servers.
(depending on the arguments in the form, we would keep track of which partner brought us which users, which apparently covers a business need for analytics)
We're currently missing CSRF protection on some endpoints, like the login one. When asked to look into it, I realized that with a static form, we'd be unable to add CSRF tokens.
It seems to be a minor issue, but it'd be nice to protect our users from login CSRF. For this reason I thought of 2 alternatives:
- add a confirmation step before logging in the user when a conflict is found in the session cookie (ruled out due to the changes in the logic flow for session management being too invasive)
- instead of a static form, let our partners use an iframe which will contain our own login form, with CSRF protection and all. This would require relaxing the
X-FRAME-OPTIONS
specifically for the page that will display this login form
Is there a better solution? I don't think that clickjacking on our login form should really be a concern (and clickjacking is normally used to do what could otherwise be trivially obtained with a CSRF, I reckon... so fixing the latter seems to have an higher priority)