I am not much experienced with brute force attacks but I was wondering

Suppose, you have a website www.example.com and you want to do brute force attack on that login form but that login form is protected by anti-CSRF token.

Is it possible to do brute force password on the CSRF protected form because a unique key created every time ?

on AntiForgeryToken versus Captcha

It is written there automated submissions are possible on CSRF protected form but I was thinking If I tried to do brute force than I have to create a valid request.

For example :


than I will use this request to brute force but this anti-CSRF token will expire after a single request than how can a brute force attack brute username and password?

  • Closely related: security.stackexchange.com/questions/66510/…
    – thexacre
    Commented Sep 21, 2014 at 3:12
  • 1
    Extra retrieving of the CSRF token just doubles the necessary request rate (assuming you require a new token per try), and makes parallel requests impossible.
    – Bergi
    Commented Sep 21, 2014 at 12:08

4 Answers 4


Simple. You read the anti-CSRF token from the newly requested login page and each time the token is attached to the server's response. In this case, before you submit a POST request, you first read the response to your GET request from the server and the new token will be attached to it. Then you use it to generate new brute-force POST request. There may be other problems you'll come across, like say request rate limiting and so on, but the anti-CSRF token itself doesn't protect against brute force attacks.

  • You'll also need to submit the session cookie that goes with the request/response.
    – Sparkup
    Commented Mar 26, 2015 at 16:56
  • True, but when you said "the token" it implied that there's one variable to return when there are two (token in body and cookie in header).
    – Sparkup
    Commented Mar 27, 2015 at 7:21

An attacker can conduct a bruteforce attack using Burp Intruder, with an extender extension to handle the CSRF token. Adding a captcha to the login page doesn't solve the problem, it raises the bar by forcing the attacker to break the captcha cracking service at 1,000 solutions for $1.

To answer your question, neither a captcha nor a CSRF token is proper defense. A secure login system should use multi-factor authentication.

  • 1
    And something like fail2ban, and, considering that the attacker may have a large number of IP addresses at his disposal, temporary account lockouts (regardless of IP address) after too many failed login attempts. This latter measure can be exploited to create a DoS attack though.
    – lzam
    Commented Sep 21, 2014 at 6:10
  • A captcha is a proper defense, it is just one that can be circumvented by either applying the right technology (e.g. script that can accurately OCR the characters) or manual human effort. Not all attackers are capable or willing to do that. Same goes for scripting in the retrieval of a CSRF token before password guessing, albeit that requirement is much easier to overcome.
    – PwdRsch
    Commented Sep 21, 2014 at 19:38

CRSF attacks work by tricking a user (usually already logged in), into performing a request that servers the end of the attacker (either by getting him to click on a hyperlink, through a method such as XSS).

An anti-CSRF token protects sensitive requests, by requiring an unpredictable value (provided to the user on an earlier page) to be sent as part of sensitive requests. The attacker has no way of knowing what this value will be, so he cannot forge the request properly.

This isn't going to have any real effect on a login page though. In most normal cases, a login page is accessible to everyone. Even if the POST request for the login form requires a CSRF token send by the login webpage, there is nothing preventing the attacker from repeatedly visiting the login page, getting a new, valid, anti-CSRF each time.


There are already loads of great answers already on CSRF here so I thought I would extend on them by offering an alternative approach to protecting against such attacks. If you are using Apache I would recommend using mod_evasive as this will protect against brute force attacks and also DOS attacks. If you are running IIS you can use the Dynamic IP Restrictions extension. You can configure rules in Nginx or using a Web Application Firewall would be a more sophisticated approach. Hope this helps.

You must log in to answer this question.

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