Regarding Anti-Cheat measures

[JulianStiebler]

Hey!

So far i didnt found the time to spin up a copy of this server, i am also no expert in those fields in general, but i wanted to propose some Ideas alrady and might spin up a copy locally over the coming days and try a bit aswell.

Cheating currently is getting very rampant and beloved. They only cheat themselfs, but since u seemed to start caring here some ideas;

JWT Token

Short-Lived JWT Tokens These tokens can ensure that even if someone captures a token, it will expire quickly. The tokens are also generated and validated server-side, making it difficult to forge valid tokens. Ideally this secret is set to an enviroment variable.

Protection against injected javascript

• Integrity Checks
  • Subresource Integrity & Strict CSP
• More secure headers

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Nonce Token

Add another token to prevet replay attacks, basically editing and resending a payload, the dumb-mans devtool option. So that each request can only be used once. This would add to the payload some extra data, and the token generation and validaiton would be server sided.

We just need to ensure that even if you run the same generation code in for exampe javascript, the result is different if not ran at the exact same time and hide each secret ideally with a enviroment variable.

Ideas regarding game-code itself

• Move the saving mechanism to the start of each wave, and validate that the save got triggered by a transfer between waves. Reject any data that does not follow this rule.
• Or keep it at the end and validate that the save can only be triggered by a pokemon's faint
• At most theyre should be just minimal value increases.
  • Client side validate minimum constraints; Not more than 6x Pokemon at a time can change theyre data at once etc.
    • Define thresholds client sided how much values can change over a given time; Total HP cant increase by 500 in a second, neither can money or such unless tied to a state (saving)
• Game State Validation; Implement logic to validate the game state, ensuring it adheres to expected progression of save data.

---

Most of those approaches would add onto the savadata and just minimally highering the payload size and server load.
Nonce-tokens would already protect against the usual "Edit and resend payload". Unsure how impactful JWT tokens are in this case.

type Payload struct {
    #AlreadyExistingData    string   `json:"data"`
    Nonce                   string   `json:"nonce"`
    JWTToken                string   `json:"token"`
    ClientSessionId         string   `json:"sessionId"`
}```

[JulianStiebler]

If i were to test some things locally, what would be considered solutions?

I'd wrap everything regarding save data in transactions definetly atleast the handleUpdateAll.

Just lemme know where i can start trying.

[CuriousRookie]

i'm not sure, post this issue on Discord or Pokerogue might have more people discussing it, like pagefaultgames/pokerogue#1914

[SirzBenjie]

@JulianStiebler
Are you still active at all?
We have new lifeblood in the development team and I'd love to hear your input on this.

[JulianStiebler]

@SirzBenjie
I am still active; though focused on other things. Depends what is meant with my input i surely can have some look again.