- Why Score List Hack Attacks Matter
- Protecting the Score List
- Real-Life Example
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Protecting the Score List
So far in this series, we've taken a close look at where games fail to protect their score lists. Now let's examine what can work. Ironically, only two of the games we tested for this series kept us from posting a new score. Let's outline some steps we suggest, and take an internal look at one of the games that defeated our attempts at posting a high score.
Server-Side Code
Above all, we recommend that you place as much of the game's code as possible on the server. This may mean that your server will have to do more, and that you will have to pass lots of data to and from the server, but this technique essentially creates a very difficult obstacle for a score list attacker.
Hard-Coded IP Addresses
When data is passed from a client's game to the server, use static IPs. This approach prevents an attacker from using DNS spoofing to redirect the request to a server of her choice. This strategy doesn't completely protect you, because the attacker could set up her computer in a custom network with static IP addresses. However, it's yet another—and more difficult—obstacle.
Checksum the Game File
When the game is launched, it's a good idea to run a quick checksum to ensure that the game has not been altered. With this type of protection in place, it would be very hard for an attacker to alter the game file. Once an addition or subtraction was made, the checksum values would not match, and the game could be programmed to post a false score. We don't recommend disabling the game, but instead let the attacker spend hours trying to figure out why the score won't post.
Validate the Score's Possibility
If a game can only score so many points per level, the server-side code should check to make sure that the posted score is possible. For example, most games allowed us to post millions of points on level 1, which should not be possible. A quick check on the server would have raised an alarm and could have ignored the posted score. Other checks include predictable incremental time shift for a timed game, or improbable feats that should not be possible in the game. For example, we were able to win one game by altering the starting point of a spaceship. Instead of having to make its way through the game, our game started the ship right on top of the finish line.
Host, IP, POST, Referrer, Cookies, Etc.
Many properties of an HTTP request can be monitored for invalid entries. Sites use these properties to check whether the posting game is actually hosted on their server, preventing people from stealing the game and calling it their own. Cookies can also be used to hold relevant information that will not be obvious to the attacker. Other options include using SSL encryption (an attacker can set up a fake SSL server) or even using IP blocking after numerous false attempts (this can be avoided by using proxy servers).