CSRF token is only valid after first ajax request

Asked

Viewed 115 times

0

I am building a login system via ajax and using a token, saving in a SESSION, passed by javascript, the idea is that each page "Reload" is created a new token to avoid Force and etc, but as I am sending via ajax, the token is only valid on the first request, if the user misses the user/password the token is invalid and it is no longer possible to log in even putting the correct data, how can I get around this situation?

  • How you are assigning the token value in the form?

  • I declared a global javascript variable in the header that comes from php, I did not put an input because it avoids Brute-force.

  • I have my doubts about how useful this is for Joy-Force. Just have the attacker pick up the token and send it. It would take twice as many requisitions (and depending on the construction, one of them could be a HEAD requisition, which would be even faster), but not by a long shot. To avoid Bear-force I think only by creating Rate-Limit. To increase the cost, you could add some captcha and add a 2FA next to the password, so the attacker would have to match two pieces of information instead of just the password. Anyway, the CSRF-Token for me should be only against CSRF, nothing more than it.

  • If you’re worried about your own CSRF Force (trying to hit a CRSF), I don’t think that would be a problem. If you for example generate a token 128 bits would be enough, if you want to use a random_bytes(64) (512 bits) would already be much more than enough. Since compare safely (hash_equals) the attacker will have to look for all the possibilities even. The issue may be other vulnerabilities, such as Session Fixation, so the attacker would already know which CSRF-Token the other user has and etc.

  • To avoid SQL testing as well, since the token is in javascript and not in the html input, sqlmap , for example, html capture, when it is placed in javascript it is almost impossible to test.

  • many Brute-force programs follow the same logic, only capturing data that is directly in form fields in html

  • If your concern is "programs" in fact this may hinder, but who will use it are people with little knowledge, Script Kiddie. But anyone with more knowledge will be able to get the javascript data and replicate the request, this should be the biggest concern in my view. Fooling automatic checks is easy, so much so that until today there are companies specialized in code audit/pentest, executed by a human. What avoids SQL Injection is not CSRF-Token, never has been and never will be.

  • I know, but just putting the fields to the test, it already generates a lot of requests to the server.

Show 3 more comments
No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.