Mitigating Login CSRF on 3rd party websites

Question

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)

Answer 1

You could check the Referrer header. This is often recommended against when there are better alternatives, but as far as I know it's not a particularly bad technique and only recommended against because some users strip the header for privacy reasons, and historically some popular browser plugins had vulnerabilities that allowed the Referrer header to be manipulated.

(I think iframes are the best solution here if you can use them. Click-jacking against a login form doesn't seem like a realistic worry. Second-best solution, using some javascript to do an AJAX request against your domain per berdario's solution maybe with a Referrer-header-check fallback for browsers that don't support cross-origin requests.)

Answer 2

I realized that there's another possible solution:

Create an endpoint that will return a CSRF token, return a Access-Control-Allow-Origin header that will grant access exclusively to our partners' domains, and add some javascript that will fetch this token and modify the (otherwise static) form by adding it as an hidden field.

This would remove the need to use iframes, but I think that security-wise is an inferior solution: the more partner domains will be added, the bigger the risk that one day one of these will disappear, we will forget to remove it from the header and the domain name will be squatted... potentially exposing ALL our endpoints to CSRF attacks again. (compared to the insignificant clickjacking risk on the login form only).

Answer 3

I think you need to implement one of the best practices for login, limit the number of login attempts (for instance, 5 attempts), after that you should block the account for some minutes (for instance, 30 minutes). I think it is a good solution, because you can control the automation attempts (bruce force attack) in a easy way.