#648 invalid race post request

[bkbCodes]

---

Directly posting to API creates invalid races : #648

Discord Username: @.d_k5g_1am_go.

What type of PR is this? (select all that apply)

• 🍕 Feature
• 🐛 Bug Fix
• 🚧 Breaking Change
• 🧑‍💻 Code Refactor
• 📝 Documentation Update

Description

Added data integrity with hashes to patch the stats boost exploit. This PR deals with 9999 average CPM cheat.

Related Tickets & Documents

• Related Issue [BUG]: Directly posting to API creates unvalid races #648
• Closes [BUG]: Directly posting to API creates unvalid races #648

QA Instructions, Screenshots, Recordings

UI accessibility concerns?

Added/updated tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

[optional] Are there any post deployment tasks we need to perform?

Check DB schema update

[optional] What gif best describes this PR or how it makes you feel?

[scape76]

why do we need transaction in here?)

[bkbCodes]

This is needed for data migration part. To introduce new token field into database. As well as to update token every 7 days to strengthen the security

[scape76]

don't you think it has to be called on the server?
Otherwise I could get the result of it (tokenAndStamp) in the network tab
and then make a call to saveUserResultAction with invalid cpm amount

[webdevcody]

@bkbCodes I'm not sure I understand what this is doing. Could you explain more how this helps prevent the exploits so as I read through the code it makes more sense?

[bkbCodes]

@webdevcody @scape76 sure, here you go.
Starting step is when user completed race and is about to submit it.

Prior to this we directly post the details of race, like, cpm, accuracy, time taken etc. This allowed the exploit of re-sending the same request with updated value such as 10000cpm, 100 accuracy, and to make it work better exploiters also used the newly generated raceID. Since, all details are now legitimate this got accepted, marking the completion of exploit.

Now, instead of submitting it directly we do following:

1. Get a signature token from DB (unique signature token), used for generating a hash of the race details.
2. After getting the token, stringfy the race results and create it's hash.
3. And now we send race result along with its hash.

Now at server side:

1. We receive the race result with the hash.
2. Now, server gets the signature token of the user from DB.
3. We stringfy the received data and create its hash.
4. Now, we compare both hashes, if equal, then, all is good we proceed forward, else, data is tampered so ignore the request.

This is main working.
To make it more robust client will get a token as well as a random number that needs to be add to data before hashing to make it difficult to break. And this random number is stored in DB and client can only read it and server can read it and update it. This part was done to avoid replay attack, say I got an impressive race with 800cpm and 100% accuracy, I can resend this multiple times to boost my overall stats, as hash value will be same if no randomness was present.

@scape76 this is the reason I used getUserTokenAndStamp()