3

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)

  • 1
    Why do you need CSRF protection for a login form? – James Cameron Mar 24 '16 at 9:53
  • 1
    It's a login CSRF: definitely not a serious vulnerability by itself, but it's still worthwhile to prevent abuse. The same thing has been found and fixed on HackerNews 1 month ago: news.ycombinator.com/item?id=11177673 and in a commercial site in which the user can actually purchase goods/services the issue is obviously slightly more important than on HN – berdario Mar 24 '16 at 11:25
  • Not sure I follow. Is the "static login form" a part of the 3rd partys website? – Anders Mar 24 '16 at 12:05
  • sort of, yes: we created the form, and then this would be included by our partner on their site (where they'd handle styling, css...) – berdario Mar 24 '16 at 12:31
  • Might be worth considering SAML so you run an IdP and clients are an SP. The IdP could use different styling/template for different SPs. – Phil Lello Mar 24 '16 at 19:55
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.)

1

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).

0

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.

  • 1
    I don't think this would help against a targeted attack against one of our users, but it's definitely something that we should do regardless. Thank you for reminding – berdario Mar 25 '16 at 14:39
  • If an attacker was trying to get victims to log into the attacker's own account that they knew the password to, then there wouldn't be any failed attempts. Login rate-limiting doesn't address the attack at all. – Macil Mar 25 '16 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.