XSS tokens? You mean XSRF (CSRF) tokens? Even if your users use Tor, the IP is not changed in every request because it will use one exit node until the Tor user decides to change this.

Sure, name of the token isn't that important. It's not to prevent a Csrf attack, so calling it Csrf token is misleading.

Ok, can you please elaborate a little bit more on what you mean by an XSS token? Session token?

IP change on every request is exactly what we are seeing from Onavo. So this is not a theoretical use case. I'm pretty sure you can configure Tor to do the same.

XSS Token = encrypt(requesting IP, secret, salt, timestamp) ---- the server can then decrypt the token and match the encrypted ip with the ip making the login request

I'm not an Onavo user so I can't say anything about that. I do use Tor and although it is possible to do this, it is not default behavior. I think you should ask yourself if you want your users to be able to work with your system if their IP addresses change every request.

Agreed, however there appears now to be a substantial amount of users with this problem. I'm really curious if (a) this is an attack that is usually considered and (b) what other companies do to prevent this

Instead of using the IP - what about encrypting the username instead?

The problem here is that the attacker can then generate the xss token and send it to the user. This defeats the whole purpose unfortunately.

Well, that's assuming the attacker knows the username. How about this. Generate a secret token upon registration which is stored in your back-end system(s) and never displayed to your users and use that as one of your secrets during the encryption process.

Could you elaborate a little how this would prevent the attack(s) outlined in the question?

Apparently I misunderstood, I thought it was an issue after authentication. After re-reading your message it's a token that you want a user to retrieve and submit during the authentication process. Isn't this what an anti CSRF token is for? That way the system can determine the origin of the request.

Yes, but an (anti) CSRF token is designed to be used with authenticated users and tied to the user session. So the (anti) XSS token is now tied to the IP instead of the session (because we don't have one yet). However with the IP changing this becomes problematic as described.

Many security consultants, including myself, believed that anti CSRF tokens were meant for state changing requests only (authenticated). However, I have changed my opinion on that. Generating an anti CSRF token on a login page will prevent the issues you describe. Using such tokens is only to determine the origin of the request. Anti CSRF tokens can be implemented in two ways, session based (as you described) and also request based. I think implementing this would solve your issue.

Sorry, you totally lost me there. I'm not sure how CSRF tokens apply to the problem at all. Can you please describe when a token with what information is generated and how it's used in the auth flow.

In your "Sort-of-Solution" you state: "The login attempt is made only if the token is valid......" So at the login page, a token (anti CSRF) is generated and sent in the response of the login page. The token can be placed in a hidden input field. The user enters credentials and sends the POST request, containing the token, username and password. Server side the token is checked, if the token is valid, verify the username and password. If the token is incorrect stop the authentication process.

Correct. But this does not prevent the attacker from generating the token themselves and then serving it to the user through the malicious website. A token once generated can be used by who-ever wants to use it. We can tie it to the username which might improve security slightly but doesn't prevent the issue.

Hello!

How would an attacker generate the token? You generate the token server side and validate if the token matches or not, also on the server side. Or do you mean if an attacker grabs a valid token from the login page? In that case you could use both the hidden input field a response header, both need to match and be verified server side.

and response header* (typo)

Yes, if the attacker grabs a valid token from a login page that they requested (not from the victims browser). I'm not sure how to protect against this.. how does the response header help here?

The response header can not be controlled by an attacker

So let's say you sent an extra header called X-Anti-CSRF

with the token value

you do two checks

first does the token in the hidden input field matches against the token in the response header

If that's valid, check the server side if the token matches

if that matches the authentication process can be initiated

e.g. checking username and password

Another idea that just popped up in my mind is MFA

I'm not sure why that whole request can't be done from the victims browser. We can put in what-ever headers and fields into the request. The anti csrf token comes back from a token endpoint. The requests don't happen "together". Let me put a quick flow diagram together

imgur.com/WDxKBIT

If we don't use the request ip address in the token this attack can always be carried out imo. I'd be interested in how your suggestion would prevent it.

Let me have a look at your diagram

Through a malicious website.... you mean click jacking?

I trick a user to go to any website where I have control over the content. They don't need to do anything, just go to the website.

Oke so from the malicious site you send a request to your application

When the user visits the malicious site, it is automatically executed

double submit would do the trick for you but that requires you to also have an anti CSRF cookie - and you can't handle cookies right?

Correct, no cookies

You also mentioned that CORS is implemented

Doesn't that prevent a malicious website from sending a POST request to your authentication mechanism?

It does not. The response can not be read, but the request still goes through. Have a look at the specs for pre-flight requests.

Yeah, sent an OPTIONS request...

Also note that CORS is only implemented in IE 8+

But yeah, maybe moving the token into the header instead of having it in the body is the better option in general

Indeed

Oh you're handling older web clients as well? < IE 7?

handling / support

Not < IE 7, but currently IE 7, yes

Hmm, that's a company policy? I'd recommend reconsidering that because of new security standards etc. Not to mention the vulnerabilities in older browsers....

I guess if we can assume CORS the token just needs to be required as a header (opposed to as a parameter)

In which case we don't need the header at all

So we can just require a "X-REQUIRE-CORS: 1" header

Which is a header

What do you mean "it's a header"?