In the following steps we will be automating CSRF testing:

1. CSRF is a vulnerability that can be present in both GET and POST method transactions. DVWA offers a good example of a GET method CSRF vulnerability. The application allows the users to update their password by submitting the new value twice via the GET method parameters, as follows:

2. Because of a lack of CSRF controls, it is easy to exploit this vulnerability. If a user of the web application can be tricked into accessing a URL with preconfigured values for the password_new and password_conf parameters, an attacker could force the victim to change the password to one of the attacker's choice.
3. The following URL is an example of this exploit. If this link were followed by the victim, their password would be changed to compromised.

    http://172.16.69.128/dvwa/vulnerabilities/csrf/?
    password_new=compromised&password_conf=compromised&Change=Change#

4. However, it is rarely this simple to exploit a CSRF vulnerability. This is because most developers are at least security-conscious enough to not perform secure transactions using GET method parameters. A good example of an application that is vulnerable to the POST method CSRF is the blog functionality of the Mutillidae application, which is shown as follows:

5. In the previous request, we can see that the contents of the blog entry submitted by an authenticated user are sent via the blog_entry POST method parameter. To exploit the lack of CSRF controls, an attacker would need to craft a malicious web page that would cause the victim to submit the desired parameters. The following is an example of a POST method CSRF attack:

6. The malicious web page uses an HTML form that returns to the vulnerable server with several hidden input fields that correspond to the same inputs required for the submission of a blog entry request in the Mutillidae application. Additionally, JavaScript is used to submit the form. All of this will happen without any action performed on the part of the victim. Consider the following example:

7. To deploy this malicious web content, it should be moved to the web root directory. In Kali Linux, the default Apache web root directory is /var/www/. Also, ensure that the Apache2 service is running. Have a look at the following screenshot:

8. When an authenticated victim browses to the malicious page, the victim is automatically redirected to the Mutillidae blog application and the blog post HACKED is submitted.