This year, we’ve provided a full suite of unit tests related to site functionality to help you understand what functionality must be preserved while you are fixing the code. There will be another suite of hidden unit tests that we’ll run when you submit your code, which will identify which vulnerabilities you have fixed and which ones you have not. Whoever scores the highest wins!

How to play

Visit https://appsec.saintcon.community/ to get started.

A basic understanding of programming is necessary to compete in this challenge. If you would like help getting started, come visit the AppSec community – they will help you find and fix one easy vulnerability.

Rules:

• Hacking this site, the submission mechanism, or anything to do with this challenge is strictly forbidden. You are welcome to run the code on your own host and hack it there.

• Your submission will not work if you try to make changes to more than what is packaged with the make-package.py file. Limit your changes to the files (and directories) listed there.

• File uploads must be less than 4MB in size (you won’t need anything close to that large).

• Submissions can be made once per user per 5 minutes (and duplicate submissions will not be scored).

• Prizes will be awarded to the winners at the awards ceremony.

• The contest starts at 12pm on Tuesday and ends at 9am on Friday.

• Tiebreaks go to the first submission.

• Don’t try to hardcode your way past the functionality tests.

• If something doesn’t seem to be working, please visit the AppSec Community, use the #appsec challenge in Discord, or message @sketrik directly.

  
  Instructions:

• To get started, clone this repo.

• Your task is to find and fix as many vulnerabilities as you can in the code in this project.

• Instructions on how to run the project can be found in the README for the repo.

• Once you are ready to submit your code, run the make-package.py script (included in the repo) to create a zip file containing only the necessary files, and upload this zip below.

• It can take up to 15 minutes for your code to be scored, depending on submission volume.

• You can view your submissions on your profile page.

• Only your highest-scoring submission will be displayed on the scoreboard.

• The max score is 100. All vulnerabilities scored present high or critical impact to the application. Examples of the types of vulnerabilities you might find in the application include SSTI, SSRF,
  XSS, and SQLi.

• Please note that the application must still function correctly – an unusable application is not secure. The definition of “function correctly” is the unit tests that have been provided. This is effectively the same set of unit tests that the scoring engine uses to check that the program is functioning correctly (although it is possible production tests will have different input).
  Your vulnerability fixes should handle malicious input gracefully rather than blocking it outright. For example, you should parameterize SQL queries instead of blocking all input that contains an apostrophe.

• Vulnerability tests will not be run on code that doesn’t pass all of the unit tests.