1

This is a real world scenario. I'm trying to provide all the details necessary.

Summary

A user changes their IP with every request using a cookieless browser. How can I secure their login requests?

Setup

  • Restful API and thin JS web client
  • CSRF Token GET Endpoint that generates csrf token which is tied to requesting IP
  • Login POST Endpoint using parameters email, password and csrf_token
  • Access-Control-Allow-Origin is set, so responses can only be retrieved from non attacker website. However pre-flight request is not issued as per specs.
  • There is a request cooldown per IP Address
  • User using browser that is cookieless and has no local storage
  • User changing their IP Address every request, e.g. using Tor or Onavo

Problem

Since the IP address changes for every request, the csrf token is never valid and the user can not log in.

We could stop associating the csrf token with the IP. However then we would allow an attacker to generate their own csrf token and send it to the user (which defeats the whole purpose). I.e. the attacker could now rate limit a user in the background and prevent them from logging in when they visit our site.

Question

The only reference I found suggested to use cookies (which we can't do).

What should we best do here to allow the user to log in while still preventing csrf?

1 Answer 1

0

So this is a REST-ful API that you're working with and your clients are using browsers that don't support cookies, ergo authentication to your API is done via an Authorization header? And I take it that the contents of this Authorization header are populated per the contents of the response from the login API endpoint?

If this is the case, your API is already protected against CSRF. CSRF against the login endpoint would only work if the response from the server set a cookie within the victim's browser which was then used to authenticate subsequent requests.

3
  • (1) Yes, this is correct (2) Agreed, against a traditional CSRF attack the api is protected since cookies are not used. However consider the attack scenario I described. Is this not something to worry about? A website could be used to deliberately block a user from accessing our website and it would look like the user doing it.
    – vincent
    Commented Sep 12, 2017 at 3:55
  • I'm not sure I follow - how is CSRF related to blocking a user from accessing a website? If the requests that are launched surreptitiously from a victim's browser do not contain any authenticating information then CSRF is not possible. Commented Sep 12, 2017 at 14:18
  • You are correct. I've confused CSRF with XSS attack. I'm accepting this answer and will ask for the specific attack separately. Cheers!
    – vincent
    Commented Sep 12, 2017 at 16:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .