Security Assessment of Scorecenter

Prepared by Gabe Joseph • 4/30/2013

Introduction

This assessment tests the security of the ScoreCenter web application developed by @pattra for Comp20 assignment 5. According to the specifications she followed from her client, ScoreCenter is "a web application that maintains high scores for HTML5 games" by providing an API for other developers to submit and retrieve the scores their games produce. It also offers a web interface where users can see all scores submitted, and search for scores by username. However, vulnerabilities in the application currently make it unsuitable for public use. This document identifies those vulnerabilities and suggests solutions for them.

What counts as a vulnerability? That's a tough question, because my client's client's (or client**; many levels of client-indirection here) specifications demanded inherent insecurities. Most importantly, authentication is neither required nor allowed in the submission API specification, so anyone can submit a high score for any game under any username, with any score amount (which makes the highness of a "high score" dubious). At the least, implementing an API key, so each game accepts submissions from only certain developers, would be necessary to ensure the data is valid. Therefore, this assessment focuses mainly on vulnerabilities in the code, not how the API can be (ab)used with false submissions, which is arguably the biggest insecurity of all.

Methodology

Testing was first carried out "black-box", using just what would be available to an attacker. However, I ran all code locally, and therefore did have to modify it slightly to connect to a local mongo instance and not Heroku's. Using just simple tools (curl and an HTML form I'd previously written to test my own code), I found multiple vulnerabilities. I then reviewed the code to find more logic errors and opportunities for server-side exploitation.

Abstract of Findings

As with most security issues, all the vulnerabilities in this application stem from putting too much faith in external input and assuming, not asserting, its correctness. Multiple vulnerabilities let an attacker crash the website by submitting unexpectedly-formatted scores or user searches. Fortunately, the site does prevent code that attackers could submit as a score from running in users' browsers when they visit the site, which could change the site's appearance or crash a user's browser. However, other websites that store their scores in ScoreCenter are at risk of the same attack, unless they also use proper security checks against the results ScoreCenter gives them.

Issues Found

  1. Cross-Cross-Site Scripting

  2. Server crash on invalid JSON

  3. Injection of additional database fields

  4. Arbitrary queries and JavaScript execution on Mongo

Conclusion

Issues with ScoreCenter make it easy to render both the site and the clients it serves inoperable. Following the recommendations given will significantly reduce the site's vulnerability to these basic attacks. Fortunately, all the changes are easy to implement. However, the obvious structural vulnerability will still remain, which lets anyone submit any score for any game, meaning that no scores listed can really be trusted. Therefore, though these problems could be fixed at minimal cost, the most prudent action would be to fix the flaws, restructure the API to verify who is submitting scores, and conduct a more thorough follow-up evaluation. Such a task would cost approximately $600, which is a small price to pay for safety, don't you think?