Scott McNeany
2020-11-28 07:08:07
You can’t trust data coming from the client. Period.
You should consider moving the calculation logic to the server and just sending the raw values needed to perform the calculation. You can easily get sub-second response times sending the data to the server, so the user won’t notice a lag.
If you need offline connectivity, then you’ll need to duplicate the business logic on both the client and the server.
But the raw values can still be compromised because eggs are eggs and i can’t trust data coming from the client, right? Too bad... would it be worth to do some source code obfuscation or other techniques to secure a static key or something? I have read about it in OWASP recommendations but it seems its more a compromise solution, isnt it?
It really depends on your scenario how far you take it. If your user is entering the quantity of an item to purchase, send just the quantity to the server and have it calculate the total cost. I can’t think of a scenario where you’re allowing user input but need to trust it, because as you said there are many ways to manipulate it on the device or in transit before it reaches the server.
The scenario is a game and of course i want to reduce the number of cheater as much as possible. So, it should be guaranteed that the values are really from the users input (not a bot) and the values are measured and calculated in my way not the hackers way :D
Thank you for the clarification. In that case I would make the user is authenticated using OpenIdConnect/OAuth and the request contains an a valid access token. For bot detection you can look at a web application firewall with bot detection.
I have to thank you for your time ;). "I would make the user is authenticated using OpenIdConnect/OAuth" - done. "For bot detection you can look at a web application firewall" - I wanted to give ModSecurity a try, but I can't imagine how that could detect bots. From my view it's very hard to distinguish.