CSRF proof of concept with OWASP ZAP
This article introduces CSRF (cross-site request forgery) vulnerability and demonstrates how to prepare a CSRF proof of concept with OWASP ZAP.
Cross-site request forgery
The vulnerability allows an attacker to forge a user request. Consequently, the user does what the attacker wants. Here’s an example:
I. Social engineering is used to lure the user to the attacker’s website. Simultaneously, the user is logged in to bank X.
II. Let’s assume, that the bank X’s money transfer form is vulnerable to CSRF (no CSRF token, no authorization password). The attacker prepares an exploit that transfers the user’s money to his account and puts it on his website.
III. When the user visits the site of the attacker, the exploit is launched.
IV. The request of money transfer is sent by the user to bank X. From the perspective of bank X, everything is fine (with a valid authentication cookie.)
Metasploitable is a Linux based virtual machine that is deliberately vulnerable.  It can be used, for example, to practice penetration testing skills. The machine is vulnerable and should not operate in bridge mode.
OWASP Mutillidae II is web application that’s also deliberately vulnerable (OWASP Top 10 vulnerabilities.) . It’s a part of Metasploitable (edit /var/www/mutillidae/config.inc on Metasploitable and set $dbname = ‘owasp10’ to get OWASP Mutillidae II working.) One can use OWASP Mutillidae II to play with web application security.
OWASP Zed Attack Proxy (ZAP) is a penetration testing tool for web site security testing . This article presents how to use OWASP ZAP to prepare CSRF proof of concept.
OWASP Mutillidae II – a form for adding new entries to a blog
This form is available in Metasploitable at 192.168.56.101/mutillidae/index.php?page=add-to-your-blog.php (192.168.56.101 is the IP address of Metasploitable.)
It’s vulnerable to cross-site request forgery. Let’s set the Security Level to 0 (which can be changed using Toggle Security) and configure the browser to send traffic through OWASP ZAP. Then launch OWASP ZAP to see the request that will be generated, and add an exemplary comment (BLOG_ENTRY_1) to the blog of USER (name of the registered user).
OWASP ZAP – analyzing the request
OWASP ZAP was launched before submitting the blog entry. Let’s see the request. The key parts were marked in the screenshot.
There’s no protection against cross-site request forgery when the Security Level is set to 0 (the value of csrf-token is SecurityIsDisabled.) One can use data from this request to prepare a CSRF proof-of concept manually. However, OWASP ZAP can do it automatically.
OWASP ZAP – generating CSRF proof of concept
Right click on the request and choose “Generate anti-CSRF test FORM.”
A new tab is opened with a CSRF proof of concept. It contains the POST parameters and values from the request. The values can be adjusted by the attacker.
Launching CSRF proof of concept
Let’s log in as a different user (USER2), who is the victim of CSRF attack. Then go to the tab with a CSRF proof of concept and click submit. Finally BLOG_ENTRY_1 is added to the blog of USER2.
This article introduced CSRF vulnerability and presented how to use OWASP ZAP to prepare a CSRF proof of concept. The user is redirected to the vulnerable form after launching the attack. Real attacks would probably use AJAX request, in order to be silent. However, the CSRF proof of concept generated by OWASP ZAP is fine for the purposes of a vulnerability demonstration.