Reflected XSS In DesignCrowd.com

In July 2014, I found an obvious reflected XSS vulnerability in DesignCrowd. In the interest of responsible disclosure, I submitted a report to the company at that time, and I can’t remember if I ever heard back. This draft post has been collecting dust ever since, so I’m finally publishing it today.

DesignCrowd is a graphic design outsourcing web site where freelance designers compete to win a bounty placed on a particular project. One feature of their website is a “manage project” page where the user can see all of the designs that have been submitted. If you don’t like a design, you can eliminate it from the competition by clicking “Eliminate this design”. The site displays a message at the top saying “Design eliminated successfully!”

The developer in me could not help but notice a URL parameter called “successMsg”.  It is base64 encoded, so it’s not immediately clear what it means.

$ echo "RGVzaWduIGVsaW1pbmF0ZWQgc3VjY2Vzc2Z1bGx5IQ==" | base64 -d
Design eliminated successfully!

Hmm… This looks bad. Is this an XSS vector? Let’s base64 encode an attack.

$ echo "<script>alert(1)</script>" | base64
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pgo=

Now put this string into the URL parameter and push the big red button.

Clearly this is exploitable. What are the possible effects?

The site uses a cookie called CustomSessionID to identify the session, and that cookie is not HTTP-only, making it trivial to steal the session ID using the reflected XSS vulnerability. Fortunately, this site does not appear to store credit card data. It has some PII (name, address, phone, etc.), but that information is voluntary. There is one really bad thing the attacker can do: a password change doesn’t require the old password, so an attacker could easily change a user’s password!

I find this flaw interesting because of its implications for vulnerability analysis. Human intuition recognizes the flaw quite quickly: the name of the query parameter and the base64 encoding are red flags to any person who knows what to look for. At the same time, base64 encoding will almost certainly fool any heuristic vulnerability scanning tools.

The uncomfortable conclusion is that most automated vulnerability scanning tools are hopelessly naive. In the short term, this underlines the continued need for human expertise in infosec, but in the long term it points towards the types of security tools the industry needs to develop: tools that blend multiple forms of analysis and are capable of understanding the types of contextual clues that are obvious to humans.