Phase 3: Vulnerability Assessment

[ponga2112]

Ensuring that our webapp has no dom-based XSS / content injection.. or ay other vulnerabilities in it.

[c-h-a-n-c-e]

Update on testing:

• no findings via URL manipulation, fuzzed before and after anchor tag

• client state control possible via cookie parameter tampering.. decode base64/change handle, flag, or point values/encode base64 and set as new cookie value. flag values and points values greater than maximum (10flg,1000pts) appear to dump the client state entirely and reset. basically this can only be used to jump to the end with max points. BUT handle name can be controlled outside of normal bounds.. can specify which random # appended (see screeenshot attached below).

  • this is just the nature of client-side state handling.. we could probably make this more difficult to do, but honestly the only critical aspect I see is to ensure validation by the leaderboard api server of all these state values. target audience is below this level.. if someone does this, they deserve a max point value score :)

[c-h-a-n-c-e]

Possible to spam user creation requests to obtain multiple users with the same display name and same appended number. Token value for user is unique so this doesn't cause any functional issues, but could result in a filled up leaderboard like in the screenshot attached:

EDIT: retest against this issue resulted in... I think remediation. Leaderboard results show no duplicate users, but when fuzzing /api/create still getting duplicate handles in valid responses.. when trying to use those duplicate handles (max flags capture using their token value), they show up in leaderboard under a different handle number. Some sort of desync happening here.. but at the end of the day, I don't see duplicates in leaderboard so something must be happening right!

[c-h-a-n-c-e]

Would we consider this data leakage? /.git/config file accessible from web server.

[ponga2112]

Removed GIT artifacts from webroot.

[c-h-a-n-c-e]

Last issue fixed, closing out!