A vulnerability!
A couple of days ago I was contacted by Christy Philip Mathew with a short and interesting email:
I was visiting your website and found an XSS Vulnerability. Please find the URL below. Thanks
http://w3af.org/#!prettyPhoto/2,%3Ca%20onclick=%22alert%28/XSS Vulnerability/%29;%22%3E/
My first thought was: “Well, this happens to everyone, lets fix it quickly”. After some minor analysis of the URL (before clicking it, I wasn’t going to click without reading !) I realized that this was a DOM XSS. This made sense. I scan w3af.org after each big change in the blog engine, and no vulnerabilities showed up on the last scan; but I’m aware that the DOM XSS detection in our scanner is very rudimentary.
Lets fix it
The next step was to fix the vulnerability, something that I usually think is pretty easy (since I’m not usually on this side of the vulnerability report). After analyzing the JavaScript file I realized it was a modified version of jquery.prettyphoto. Since it was modified I figured out it was going to take more time to fix… but I tried to do it myself. Christy told me that the latest prettyphoto had a fix for this vulnerability, so I downloaded it and copied it to my server.
Test the URL to reproduce the vulnerability again: No alert! Fixed? Well… who knows… I had no idea what this JS did in the first place, so I had to verify that the features it provided were still working. After 5 minutes of understanding what this JS did (pretty photos is kind of generic) it was obvious that it wasn’t working anymore. The modification by the theme provider was breaking something.
After a couple of emails with the wordpress theme provider, I got a modified version of the latest pretty photo; installed it and verified the fix. Everything was working as expected.
My last step was to ask Christy to verify the fix, as he was the original reporter, he should have the last word on it. He replied shortly after my email: “Not fixed, still vulnerable”. Damn! … think… maybe it has something to do with the browser he’s using? Maybe with some cache? Yes! w3af.org is served over CloudFlare and I’ve also configured my WordPress to send out headers to cache all static files. Since the DOM XSS was in the JS file, it was cached and thus making Christy’s browser think that the site was site vulnerable. After clearing the browser cache he was able to verify the fix.
Lessons learned
- Fixing a “trivial” vulnerability can take more time than expected
- Treat your vulnerability reporters just like you want to be treated when you report a vulnerability
- Many other jquery.prettyphoto users might be at risk
- Don’t panic, it happens to all of us
SEP
About the Author:
Web Application Security Innovator, Researcher and Entrepreneur. Python Hacker.