skip to Main Content
This website use cookies which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy. To learn more or withdraw consent please click on Learn More. By continued use of this website you are consenting to our use of cookies.

Guest Blog: Writing Up a POC by Planet Zuda

Republished with permission from:

How To Write a Proof Of Concept For Security Holes
Screenshot 2015-01-12 10.32.11


We find security bugs all the time and have to write proof of concepts. Unfortunately, we struggled with being able to make a really good proof of concept for each bug. After a lot of work and help from bugcrowd, we are able to write detailed proof of concepts, which have a higher chance of getting the results you want and some places even pay more if you provide a good proof of concept.

So how do I write a good proof of concept?

Solving a murder mystery and writing a proof of concept for information security aren’t that different. Every murder mystery has to solve five questions who, what, when, where, why and how. A good proof of concept has to answer those same questions.

Let’s talk about a fictitious program called example. You were testing example and found persistent XSS. Now you need to report the issues in example to a large company. You may run into the problem of thinking that the person reading the letter understands security or understands what you’re trying to explain. This isn’t usually true. Here is an example of a bad proof of concept.

The product example has a persistent XSS due to a broken regex. Please fix this immediately.

That is a very, very bad proof of concept but you don’t know it. So how do you write a good proof of concept?

You have to think who the issue will affect, what it affects, when it will affect it, and why it is an issue. When you are explaining why you need to explain the impact, because just saying there is a security hole isn’t enough. Using a tool like the CVSS calculator and then giving the company the score from 0 to 10 and how exploitable it is on 0 to 10 helps them understand the impact the issue has on their product.

Here is an example of a good proof of concept for the fictitious program called example that accepts credit cards and comments on products. Please note that we aren’t adding in any exploit code, but in a proof of concept you have to do that.

Step 1: Download example at

Step 2: Installed the latest version of example 0.0.1 using PHP 5.4.31 and MySQL version 5.6.22 running CentOS version 6.6.

Step 3: The malicious actor must sign up for a normal account, which anyone can sign up for.

Step 4: Once signed up the malicious actor can post a comment and put the persistent xss in the parameter comment at

Step 5: Once the XSS code has been added as a comment anyone who views the page will execute the XSS. Once the XSS is executed it can lead to a full deface, redirect your users to another site or use your site to phish users information. According to the CVSS calculator this has an impact of 7.4 out of 10 and an exploit factor of 8.0 out of 10.0.

Step 6: The Persistent XSS can be fixed by using fake_function() for sanitation against code being executed or injected into the database.

Step 7: The persistent XSS issue occurs despite what PHP version, mysql version or operating system you are using.

A user is not supposed to have these types of permissions. We hope this can be fixed. Thank you for your time.

In the above proof of concept you’ve outline what can be affected, which is the product example. You’ve outlined why it can be affected by persistent XSS, where it is affected, who it affects and how the product is affected. You must remember that the person getting the email most likely has a lot of reports to go through, so thanking them for their time is the least you can do.

This is the type of report companies want to get, because they don’t have to figure out the impact and since you already did the work you can help them out by explaining everything. They will most likely really appreciate this.

About the Author:

This article was written by Ryan Satterfield of Planet Zuda. Ryan Satterfield is an information security researcher that started researching computer security at the age of 9 and has yet to stop. His company Planet Zuda has assisted web hosts with security for 8 years. He loves to hack all the things, whether it be open source code, giant sites like Google to products that aren’t supposed to connect to the internet or even to a computer. When he isn’t researching security he might be bowling, teaching a class, listening to dualcore music, or hanging out with friends.

Back To Top