防止欺诈性地提交记分牌 [英] Preventing fraudulent submission to a scoreboard

问题描述

我正在为Flash游戏开发后端，我需要将数据保存到记分牌中。

游戏将在横幅广告的许多网站上进行托管，用户将在广告中玩游戏，然后点击进入主站点以保存其详细信息。

在用户玩这个游戏并点击提交他们的分数
$ b $ ol
$ li

在后台，广告条将分数和原始网域发送到主网站上的脚本。

脚本检查域是广告所在的有效域之一

如果一切正常，脚本将创建该分数和域的哈希值，并将其存储在数据库中，并与分数一起存储。

该脚本将哈希值返回给Flash，并将其打包到打开主记分牌的getURL的查询字符串中。

记分牌页检查引用者以确保它是有效的域之一。

如果是这样的话，那么检查数据库中的散列是否是一个有效的标记

填写他们的详细信息，记录根据散列更新

上次我检查了FLash不发送引用者信息，把扳手扔进我的计划。那么，这种Flash /数据库交互模式是否已经存在？

我应该在步骤4中使用什么样的散列/校验？什么是这种操作的正确名称，它是一个哈希，校验和或其他？

我明白，作为客户端技术，Flash将永远不会这是安全的，但在我看来，像上面这样的东西是困难的，因为你要使它破解这种应用程序。

更新：我的主目标是让人们难以找到脚本的网址，将分数添加到数据库中，并简单地用假分数发送垃圾邮件。

谢谢，
Greg

我曾经在游戏行业工作过，并且在这方面做了一些工作。据我所知，从来没有人打扰提交部分的分数。

完成的方式是：

1. 以盐的形式生成一个随机数字（来自闪存）
   
2. 使用数学运算基于salt（来自闪存）编码分数
   
3. 添加校验和以确保乐谱没有任何磨损（闪光灯）
   
4. 将乐谱和任何所需数据发送到乐谱提交页面


5. 在服务器上，使用校验和验证分数没有被调和过。
   
6. 如果分数是有效的，那么插入数据库，否则拒绝


7. 如果您愿意，您可能会记录违反校验和的提交者的IP地址（也许是三个错误校验和的策略，您不在），并添加一个脚本来禁止他们访问服务器1小时，但这可能不会被要求，除非有人想破解你的代码不好。

注意：
哈希/使用自定义函数进行校验。不需要非常安全的东西。它是用盐和分数计算得来的。一些简单的数学运算，如总和，乘法和减法。


$编辑：一个简单的算法/数学的校验和

可以说你的用户得分是 5885 。

你可以产生一个随机数作为盐134789 （恒定长度，填充0）

cryptedScore = 得分 * 盐（你应该在这里使用一些更复杂的东西，但这只是一个例子）

在我们的例子中，加密的分数会是： 793233265

现在对于校验和来说，假设您希望将 253 作为校验和。
您将所有加密分数加上7 + 9 + 3 + 2 + 3 + 3 + 2 + 6 + 5 = 40 $ /
$ b

现在，您计算此分数的校验和值 -
253 - （加密分数总和％<253> ）

现在，我们有以下数字：

the salt = 134789

加密得分= 793233265 strong>

the checksum = 40

您向服务器发送请求，发送 134789793233265040 作为分数。

在分数服务器上，您可以将 793233265 除以 134789 ，给5885

使用与以前相同的函数验证校验和。

如果校验和失败，则数字被篡改。

您可能最终得到更安全的东西，但它应该做的。

I'm working on the backend for a Flash game and I need to secure the data going into the scoreboard.

The game is going to be hosted on many sites in a banner ad, the user will play the game in the advert then click through to the main site to save their details.

At the moment I am thinking along the lines of this

1. User plays the game and clicks to submit their score
2. In the background, the banner sends the score and the originating domain to a script on the main site.
3. The script check the domain is one of the valid domains the ad is being hosted on.
4. If everything is right, the script creates a hash of this score and domain and stores it in the database along side the score.
5. The script returns the hash to Flash which cobbles it onto the querystring of a getURL which opens the main scoreboard
6. The scoreboard page checks the referer to make sure it is one of the valid domains.
7. If it is it then checks the database for the hash to if it's a valid token
8. the user then fills in their details and the record is updated based on the hash

Last time I checked FLash doesn't send referer info, which kinda throws a spanner into my plan. So, is there an already established pattern for this kind of Flash/Database interaction?

What sort of Hashing/Checksuming should I use in step 4? What is the correct name for this kind of operation, is it a hash, a checksum or something else?

I understand that being a clientside technology, Flash will never actually be THAT secure, but in my mind, something like the above is about as dificult as you're going to make it to hack this kind of application.

UPDATE: My main objective is to make it harder for people to find the URL of the script that adds the score to the database and simply spam it with fake scores.

Thanks, Greg

解决方案

I have previously worked in the game industry, and did something along these lines. To my knowledge, no one ever bothered cracking the score submitting part.

The way it was done was :

1. Generate a random number as a salt (from flash)
2. Encode the score using math operations, based on the salt (from flash)
3. Add a checksum to make sure there was no tempering on the score (from flash)
4. Send the score and any required data to the score submitting page
5. On the server, validate that the score has not been tempered using the checksum
6. If the score is valid, then insert it into the database, else, reject it
7. If you want, you might log ip adresses of the submitters of scores violating the checksums (maybe a policy of three bad checksums, you're out) and add a script to ban them from accessing the server for 1h, but this will probably not be required unless someone wants to crack your code that bad.

Note : The hashing / checksuming was made using a custom function. Did not need something very secure. It was made using a computation on the salt and the score. Some simple math operations like sums, multiplications and subtractions.

---

Edit: a simple algorithm / maths for the checksum

Lets say your user has a score of 5885.
You generate a random number as a salt of 134789 (constant length, pad with 0)

cryptedScore = Score * Salt (you should use something a bit more complex here, but it is just an exemple)

In our example, the crypted score would be : 793233265

Now for the checksum, lets say you want to have a value of 253 as a checksum.
You add all the numbers of your crypted score 7+9+3+2+3+3+2+6+5 = 40

Now, you calculate the value of your checksum for this score
253 - (Sum of crypted score numbers % 253)

Now, we have the following numbers:
the salt = 134789
the crypted score = 793233265
the checksum = 40

You make a request to the server, sending 134789793233265040 as a score.

On score server, you can divide 793233265 by 134789 giving 5885 and validate the checksum using the same function as before.

If the checksum fails, then numbers have been tampered.

you could probably end up with something much more secure, but it should do the trick.

这篇关于防止欺诈性地提交记分牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！