4

Looking at this previous question, the answer suggests that using a GET request to retrieve a CSRF token in order to make a POST is a legitimate method of preventing CSRF attacks.

I have two websites, and a form is used to communicate between them -- a login form. These two sites are on separate subdomains, and the form itself on Site A is: <form method="post" action="https://siteB.com/login">..</form>

Site B requires a CSRF token to be sent in via a hidden input, so on page load, I make a JSONP call to //siteB.com/getCSRFToken, which sends back the valid token. I use javascript to insert the hidden input element into the form, the user is none-the-wiser, and the form submits properly.

Are there potential security implications to doing this? SiteB is an Express-backed Node application, so I am just using their CSRF middleware to handle generation/expiration.

Community
  • 1
Julian H. Lam
  • 143
  • 6

2 Answers2

3

In this case, I'm using it for a set of login/registration forms, so there's no information leakage

The existence of a getCSRFToken JSONP API with no other limitation on caller site is effectively a complete bypass for all CSRF protection.

If you think that is not a problem, you should just get rid of the CSRF protection system instead, as it is doing nothing for you.

If you have other forms that should still be protected, then you'd want to remove the protection from the login/registration forms.

If you do need CSRF protection on your login forms you will need to establish a cross-domain session. If site A and site B are on the same server this isn't too bad as you can create a token on one that is readable from the other. If they are separate then you have federated sessions which is a lot more work.

all they'd be able to do is allow the user to log in, right?

That may be a problem based on how your application works. What would be the upshot if, in the middle of using your application, a user could be silently switched from one account to another by a hostile site in another tab?

If, for example, the user doesn't notice their account has changed and enters sensitive information to be stored on an account that isn't theirs but an attacker's, that could be quite bad.

bobince
  • 12,534
  • 1
  • 27
  • 42
  • @bobince what if you do not use JSONP, and limit the `/getCSRFToken` route by origin, say to `siteA.com` only – bentael Nov 18 '14 at 14:39
2

The reason for CSRF tokens is to ensure that an attacker cannot force you to submit something without you knowing it. If an attacker would create a form on his/her site, say evil.com, he/she can easily fill in the CSRF token by doing the same JSONP request.

Another, although perhaps difficult to implement, is to for having siteA create a token, submit it to siteB, and the latter verifies if the CSRF is valid using some JSON call to siteA. This way, you can ensure that siteA was used to submit the form.

It's merely a "is this token correct?" versus a "give me a correct token".

ndrix
  • 3,226
  • 13
  • 17
  • Thanks @m1ke -- took me a couple read-throughs, but I see where the vulnerability lies. In this case, I'm using it for a set of login/registration forms, so there's no information leakage (or ability to make calls as somebody else). If somebody recreated the form on their site and used the CSRF reflection technique, all they'd be able to do is allow the user to log in, right? AFAIK that's not really a problem... – Julian H. Lam Apr 23 '14 at 12:29