Whenever your highscore system is based on the fact that the Flash application sends unencrpyted/unsigned highscore data via the network, that can be intercepted and manipulated/replayed. The answer follows from that: encrypt (decently!) or cryptographically sign highscore data. This, at least, makes it harder for people to crack your highscore system because they'll need to extract the secret key from your SWF file. Many people will probably give up right there. On the other hand, all it takes is a singly person to extract the key and post it somewhere.

真正的解决方案包括在Flash应用程序和高分数据库之间进行更多的通信，以便后者能够验证给定的分数是否真实。这可能很复杂，这取决于你的游戏类型。

根据我的经验，这最好是一个社会工程问题，而不是一个编程问题。与其专注于让作弊变得不可能，不如专注于通过消除作弊动机来让它变得无聊。例如，如果主要动机是公开可见的高分，那么简单地延迟高分的显示时间就可以通过消除作弊者的正反馈循环来显著减少作弊。

It is only possible by keeping the all game logic at server-side which also stores the score internally without knowledge of the user. For economical and scientific reasons, mankind can not apply this theory to all game types excluding turn-based. For e.g. keeping physics at server-side is computationally expensive and hard to get responsive as speed of hand. Even possible, while playing chess anyone can match AI chess gameplay to opponent. Therefore, better multiplayer games should also contain on-demand creativity.

你说的是所谓的“客户信任”问题。因为客户端(在这种现金中，运行在浏览器中的SWF)正在做它设计要做的事情。保存高分。

问题是，你想要确保“保存分数”请求来自你的flash电影，而不是任意的HTTP请求。一种可能的解决方案是在请求时(使用flasm)将服务器生成的令牌编码到SWF中，该令牌必须随请求一起保存高分。一旦服务器保存了该分数，令牌就过期了，不能再用于请求。

这样做的缺点是，用户每次加载flash电影只能提交一个高分——你不得不强迫他们刷新/重新加载SWF，然后他们才能再次播放新的分数。

我认为最简单的方法是在游戏每次注册一个分数时调用RegisterScore(score)这样的函数，然后对其进行编码、打包并将其作为字符串发送到php脚本。php脚本知道如何正确地解码它。这将停止对php脚本的任何直接调用，因为任何强制得分的尝试都会导致解压错误。

一种简单的方法是提供高分值的加密散列及其本身的分数。例如，当通过HTTP GET发布结果时: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

当计算这个校验和时，应该使用一个共享秘密;这个秘密永远不应该通过网络传输，而应该在PHP后端和flash前端中硬编码。上面的校验和是通过将字符串“secret”前置到分数“500”前，并通过md5sum运行来创建的。

Although this system will prevent a user from posting arbitrary scores, it does not prevent a "replay attack", where a user reposts a previously calculated score and hash combination. In the example above, a score of 500 would always produce the same hash string. Some of this risk can be mitigated by incorporating more information (such as a username, timestamp, or IP address) in the string which is to be hashed. Although this will not prevent the replay of data, it will insure that a set of data is only valid for a single user at a single time.

为了防止任何重放攻击的发生，必须创建某种类型的挑战-响应系统，例如:

The flash game ("the client") performs an HTTP GET of http://example.com/highscores.php with no parameters. This page returns two values: a randomly generated salt value, and a cryptographic hash of that salt value combined with the shared secret. This salt value should be stored in a local database of pending queries, and should have a timestamp associated with it so that it can "expire" after perhaps one minute. The flash game combines the salt value with the shared secret and calculates a hash to verify that this matches the one provided by the server. This step is necessary to prevent tampering with salt values by users, as it verifies that the salt value was actually generated by the server. The flash game combines the salt value with the shared secret, high score value, and any other relevant information (nickname, ip, timestamp), and calculates a hash. It then sends this information back to the PHP backend via HTTP GET or POST, along with the salt value, high score, and other information. The server combines the information received in the same way as on the client, and calculates a hash to verify that this matches the one provided by the client. It then also verifies that the salt value is still valid as listed in the pending query list. If both these conditions are true, it writes the high score to the high score table and returns a signed "success" message to the client. It also removes the salt value from the pending query list.

请记住，如果用户可以访问共享秘密，则上述任何技术的安全性都会受到损害

作为一种替代方法，可以通过强制客户端通过HTTPS与服务器通信，并确保客户端预先配置为只信任由您单独有权访问的特定证书颁发机构签署的证书来避免这种来回。