CSRF proof of concept with OWASP ZAP

Dawid Czagan
October 14, 2013 by
Dawid Czagan

This article introduces CSRF (cross-site request forgery) vulnerability and demonstrates how to prepare a CSRF proof of concept with OWASP ZAP.

FREE role-guided training plans

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

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. [1] 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.) [2]. 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 [3]. 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 ( 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.

What should you learn next?

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.


Dawid Czagan
Dawid Czagan

Dawid Czagan (@dawidczagan) has found security vulnerabilities in Google, Yahoo, Mozilla, Microsoft, Twitter, BlackBerry and other companies. Due to the severity of many bugs, he received numerous awards for his findings.

Dawid is founder and CEO at Silesia Security Lab, which delivers specialized security auditing services with a results-driven approach. He also works as Security Architect at Future Processing.

Dawid shares his bug hunting experience in his workshop entitled "Hacking web applications - case studies of award-winning bugs in Google, Yahoo, Mozilla and more". To find out about the latest in Dawid's work, you are invited to visit his blog (https://silesiasecuritylab.com/blog) and follow him on Twitter (@dawidczagan).