Page MenuHomeVulnz

XSS and input validation vulnerability in "Competitions" section



When choosing a player for a competition at{competition}/my-player, the web app doesn't check whether the player submitted was uploaded by the user choosing the player, nor if that player even exists. Therefore, this allows for a user to choose another person's player, or inject code which is visible in the Results tab.

Reproduction steps

  1. Log in at
  2. Annotate the value of the PHPSESSID cookie by using the developer tools available for the browser of your choice.
  3. Now, in a terminal, execute the following command, where {competition} is the competition codename and {cookie} is the value of the PHPSESSID cookie:
curl '{competition}/my-player' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Cookie: PHPSESSID={cookie}' --data 'player_name=%3Cscript%3Ealert(document.cookie)%3B%3C%2Fscript%3E&submit=' --compressed
  1. Now, load{competition}/results. An alert will pop up showing your cookies, proves that there is in fact a XSS vulnerability. Choosing a different value for the player_name parameter will set the player to that exact value, which means someone can select another person's player.

It has not been proved (and it has never been the intention as the Joc d'algorísmia is a serious and assessable activity and this could have serious consequences) that this action will imply that when playing a round the other person's player will be actually used, but this scenario remains open and is the most probable one.

What should be done?

Verify several things:

  1. When users choose a player, validate that the player exists and belongs to the user.
  2. When displaying the player's name, escape all HTML special characters.

Attack scenario

Someone could develop a Javascript script which collected the PHPSESSID of people who viewed the Results tab, and could also steal the teacher's cookies, therefore maybe gaining access to sensitive parts of the Jutge.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.


Dec 12 2018, 8:39 PM

Event Timeline

avm99963 triaged this task as Priority-1 priority.Dec 12 2018, 8:39 PM
avm99963 created this task.
avm99963 claimed this task.

On Tuesday, December 13, at 10:12 AM, a developer told me that this had been fixed, and I could verify it that same day.

Therefore, I'm marking this report as Verified and making it public because the fix is now available to everyone.

avm99963 changed the visibility from "Restricted Project (Project)" to "Public (No Login Required)".Dec 19 2018, 12:33 AM