Exploiting my own WordPress part 3 – ZAP and Securityheaders.io

TL;DR: 
ZAP find  almost a 1000 potential vulns in my site. I patch them with a plugin – or so I thought – and get MORE vulnerabilities – or do I? 

ZAP is a Flagship Project from OWASP. I adore OWASP for its work on Top 10 lists for Web and Mobile Vulnerabilities, and their Cheat Sheets for defense. I know it is in every pen testers arsenal, so let’s go look at it!

I spin up ZAP, make sure the dropdown meny in the upper right corner says “Standard mode”, write my target server into the graphical interface and click “Attack!”. The default attack consists of a spider which enumerates all the sites and an active scan. Enumeration is usually legal but  active scans, attempting injections, are generally not legal. 

ZAP lists all the links it is following. A green spot before the URL indicates that it’s a site in scope, a red spot means and external link and thus not in scope. I sort these links to make sure that all the external links are legit. They are. I see that ZAProxy doesn’t find my hidden login page. Interesting! Sometimes Security by  Obscurity works!

ZAP gives me a report with 988 yellow, orange and red flags. How is a stressed out exploratory tester supposed to sieve through all that? Are these issues actual or potential? I can imagine the security fatigue that a non-security person would feel – even I used to feel overwhelmed by ZAP.

These potential issues are sorted into five categories. Cross Site Scripting is one of them, I try out some basic XSS techniques, but I can’t manage to exploit it. Regardless of whether a defense oriented security analyst like me is able to exploit, I still want to patch this. I don’t want a test report with 700 alerts!

One of these categories is more serious than the other – Path traversal. However, for the time being I disregard the more serious potential issue for the bulk of the issues. Four of these categories are header related. What to do about that? Let’s head over to our friends at securityheaders and see what they have to say about my site?

Hmm. An F. What to do about this? This WordPress Plugin looks promising. It’s compatible with my WordPress version and it was updated two weeks ago. I perform an extra backup of the site, activate  the plugin and go to its settings page. One by one, I enable the options. I verify the change with curl -vI, to inspect what has happened to my headers, and I click around a bit on my site to see whether I broke something obvious. Then I rerun the securityheaders scan and go from F to D to C to a B to an A. I could implement Content Security Policy too, but I want to read up about it more first.

Now I do a new scan, expecting considerably less flags.

WTF? Not only did I NOT patch the existing issues, I’ve added 2, and I introduced a new category – SQL injection! This is an epic fail, but why? I curl my front page again and the headers look like they are supposed to!

After some frustrated pacing (I mean, “a refreshing coffe break”) I redo the scan. This time I only get 455 flags.

Looking closer, I see that one of the flagged pages is https://adaconf.org/wp-admin/, a page that does not exist. A reasonable hypothesis is that if it doesn’t exist it can’t have XSS protection. I also note that the X-Frame category has the exact same number of flags as the XSS category. Have they flagged the same, non-existent issues?

I curl a couple of these pages, with -vI (headers) option and –get option (the same option that ZAP uses). I get various client side error codes: 403, 405, 400, but also a couple of 200 OK.

Now I try out the ATTACK mode of ZAP. I’m a bit worried, because ATTACK may cause issues with the site, and after repeatedly bringing down this blog with wpscan yesterday, I am afraid what it my do. But to my disappointment, ATTACK mode finds the exact same number and categories of vulnerabilities as Standard Mode does. Anticlimax.

Lastly I disable the Security headers plugin and scan again. I want to verify whether the SQL injection flag is caused by the plugin. But even with security headers off, the flag is still there. That’s good, a security measure that introduces new holes is… suboptimal.