Timeline for Should we prevent this login XSS attack?
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2018 at 14:09 | answer | added | Conor Mancone | timeline score: 1 | |
| Jun 29, 2018 at 3:36 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Dec 14, 2017 at 6:49 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Nov 14, 2017 at 6:25 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 15, 2017 at 6:07 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 15, 2017 at 5:39 | answer | added | Egret | timeline score: 0 | |
| Sep 12, 2017 at 22:47 | comment | added | Macil | You could block any login requests that don't have an Origin header or Referer header referencing your site's domain. (That would however block some people who are using browsers too old to send the Origin header that also manually disabled the Referer header. I think the overlap of old browser and very uncommon settings isn't worth worrying too much about as long as you have a good error message.) | |
| Sep 12, 2017 at 19:01 | history | edited | vincent | CC BY-SA 3.0 |
added 169 characters in body
|
| Sep 12, 2017 at 18:31 | comment | added | Jeroen | Let us continue this discussion in chat. | |
| Sep 12, 2017 at 18:28 | comment | added | vincent | 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. | |
| Sep 12, 2017 at 18:15 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 18:07 | comment | added | vincent | 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. | |
| Sep 12, 2017 at 18:01 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 17:55 | comment | added | vincent | 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. | |
| Sep 12, 2017 at 17:49 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 17:40 | comment | added | vincent | Could you elaborate a little how this would prevent the attack(s) outlined in the question? | |
| Sep 12, 2017 at 17:37 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 17:32 | comment | added | vincent | 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. | |
| Sep 12, 2017 at 17:30 | comment | added | Jeroen | Instead of using the IP - what about encrypting the username instead? | |
| Sep 12, 2017 at 17:30 | comment | added | vincent | 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 | |
| Sep 12, 2017 at 17:25 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 17:24 | comment | added | vincent | 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 | |
| Sep 12, 2017 at 17:22 | comment | added | vincent | 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. | |
| Sep 12, 2017 at 17:20 | comment | added | Jeroen | Ok, can you please elaborate a little bit more on what you mean by an XSS token? Session token? | |
| Sep 12, 2017 at 17:18 | comment | added | vincent | Sure, name of the token isn't that important. It's not to prevent a Csrf attack, so calling it Csrf token is misleading. | |
| Sep 12, 2017 at 17:16 | comment | added | Jeroen | 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. | |
| Sep 12, 2017 at 16:53 | history | asked | vincent | CC BY-SA 3.0 |