HTML login form without a CSRF protection

Question

We've recently got a vulnerability report saying that one of our HTML forms in one of the internal applications is not CSRF protected. At first, we could not immediately reproduce it manually using the developer tools looking at the headers and cookies finding the XSRF-TOKEN present in the headers.

But then, we reproduced the problem in the incognito tab or a "clean" browser. The problem was in the very first login attempt only. It appears that at the moment the first login request is posted, the client does not yet have the XSRF token since this is the very first interaction between the client and the server.

Is it still a vulnerability and should be addressed if only reproduced on the very first login request? How is this kind of problem generally addressed? There probably needs to be some sort of client-server interaction before the login form submission so that the client would get the XSRF token beforehand.

Answer 1

This is called "Login CSRF" and is indeed a real problem that you should address.

While an attacker couldn't fool a victim to log in to their own account since the attacker doesn't know the user's credentials, an attacker could fool the victim into logging in to the attacker's account. This can be used to trick a victim into giving up information to the attacker as the victim believes that they are signed in as themselves.

This is indeed something that has been used to malicious ends. From Detectify:

PayPal was once vulnerable to login CSRF and the attacker could make a user log in to the attacker’s PayPal account. When the user later on paid for something online, they unknowingly added their credit card to the attacker's account.

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

Even if you can't think of any way this could be leveraged on your site, a clever attacker might. There is no reason to allow it.

So how do you block it? Even if the first action the user take is to log in, the first interaction they have with the server is to fetch the login page. Thats an opportunity to assign a CSRF-token. Then check for it on all requests that change the state of the server, including the login.

(A tangentially related vulnerability is session fixation. Having CSRF-tokens that persist past login can expose you to that, so read up on that before you start implementing a solution.)

Answer 2

As explained by Anders, lack of csrf on the login form is a serious vulnerability. There is probably numerous vector of attack, but here is another possibility that come to my mind. In the worse case, it could lead to the steal of the credentials of the victim.

If the attacker has a persistant self-xss on his account, getting the user to login on his account might be enough to trigger it, thus allowing him to change the entire source page and displaying either a sign up or a sign in form.

Here is an exploit on AirBnb exploiting the self-xss plus lack of csrf token on login form.