SuperFrog
SuperFrog

Reputation: 7674

Verifying the validity of the data sent from WebApp to Web Service

I am building a WebApp which connects to my server through a web service. Users (there is no login) which use the webapp can send their scores to the server.

The code is written mostly in javscript, so anyone can read it.

As I know there is no 100% gurantee method of doing this, I am just looking for ideas how to make it as hard as possible for users to send false scores.

Ideas? 10X!

EDIT

The server side web service is an asmx (.net) web service hosted on an IIS. I can modify it as needed.

Upvotes: 0

Views: 96

Answers (2)

bobince
bobince

Reputation: 536339

For a process (you seem to be talking about a game?) with a limited number of interaction points, you can record each user interaction and play it back to check that it results in a certain score at the server side (either in real time or later on for suspicious scores).

Otherwise (and this is typically impractical for an real-time action game where there are too many interaction points), there is not much you can do. You can have the game digitally sign the information it is submitting... but given that you are giving the full code including signing key to the client side, it is still easy for an attacker to obtain the key and sign invalid scores.

At this point you get yourself into an obfuscation arms race - how much can you make the client-side code unreadable and difficult to unravel, to prevent attackers from obtaining the key? You can never win this game, only deter the casual attacker. And ultimately you have to protect the entire client-side process from alteration, to stop all other forms of cheating (eg using Firebug to change variables like score or lives).

Upvotes: 0

Seth Greenstein
Seth Greenstein

Reputation: 153

I'd say the best thing to do would be to have a webservice call that generates a guid on the the serverside, which is passed back. This becomes your session token. It's stored on the database or in cache on the server

Each subsequent call requires the passing of the token back to the server, which validates the token. If they pass a bad token you don't update.

This will only insure that the calls come from the correct process. They won't be able to spoof the entry with a single call

Upvotes: 2

Related Questions