想象一下一个带有滚动关卡的太空射击游戏。有哪些方法可以防止恶意玩家修改游戏以获得利益?一些难以在服务器端限制的事情包括自动瞄准、窥视可见区域之外、速度作弊和其他一些行为。
有什么方法可以预防这种情况?假设服务器使用任何一种语言,客户端通过WebSocket连接。
始终假设代码100%可破解。考虑预防完全重写客户端(用于作弊)进行作弊的方法。这些可以是编写安全游戏协议的方法、服务器端检测等。
想象一下一个带有滚动关卡的太空射击游戏。有哪些方法可以防止恶意玩家修改游戏以获得利益?一些难以在服务器端限制的事情包括自动瞄准、窥视可见区域之外、速度作弊和其他一些行为。
有什么方法可以预防这种情况?假设服务器使用任何一种语言,客户端通过WebSocket连接。
始终假设代码100%可破解。考虑预防完全重写客户端(用于作弊)进行作弊的方法。这些可以是编写安全游戏协议的方法、服务器端检测等。
服务器是王者,客户端易受攻击。
使用WebSocket时,您需要做两件事:
向服务器发送游戏操作并从服务器接收游戏状态。
渲染游戏状态并将输入发送到服务器。
通过缩小代码,您无法解决这些问题。客户端上的代码只用于处理输入和显示输出。所有逻辑都必须在服务器上完成。
您只需要编写服务器端的验证。唯一的问题是,由于复杂性,游戏输入比表单输入要难得多。这与使表单安全的确切相同。
但是,在“输入有效”检测方面,您需要非常小心。您不想从游戏中踢出/禁止高技能玩家。在机器人检测的严格度和宽松度之间取得平衡非常困难。整个机器人检测领域总体上非常难。例如,Quake曾经有过一种自动瞄准检测器,在当时会将正当技能的玩家踢出。
至于防止机器人直接连接到您的WebSocket,为多人游戏设置一个单独的HTTP或HTTPS验证通道可增加安全性。使用多个Http/https/ws通道来验证客户端是否“官方”,充当某种握手形式。这将使直接连接到ws变得更加困难。
示例:
想象一个简单的多人游戏。一个二维基于房间的赛车游戏。最多n个用户在平坦的二维平台地图上竞赛,以从A到B。
假设您有一个 foolproof 系统,其中通过 HTTPS 渠道进行了复杂的身份验证,以使用户无法直接访问 WebSocket 通道并被迫通过浏览器进行访问。您可能有一个 Chrome 扩展程序来处理身份验证,并强制用户使用该扩展程序。这减小了问题领域。你无法真正防止任何人修改你的JS或编写GreaseMonkey脚本。但是,你可以通过缩小你的脚本并尽可能使你的代码加密来使它们难以修改。甚至可以添加一些虚假的方法或变量,这些方法或变量什么也不做,只是用于误导攻击者。但是,如果给予足够的时间,这些方法都不是完全可靠的,因为一旦你的代码传输到客户端,它就不再属于你。
他们不必触碰您的客户端代码--他们只需嗅探并实现您的Websocket协议,并编写一个假装是人类玩家的微小代理。
更新:问题有几个部分,我没有即时答案,但可以考虑以下问题来评估各种选项:
当然,你设置的许多路障可以被规避,但对玩家和你来说代价是什么?请参见 "消耗战。"
您可以在浏览器上编辑JavaScript并使其工作。有些人建议向服务器发出调用以进行检查。因此,在向服务器发出调用后,将在服务器上进行验证。一旦验证通过,它将返回客户端并执行操作。但我认为即使这也不是绝对可靠的。
例如,对于基本的登录操作:在Angular中,当向服务器发出调用时,后端会验证用户名和密码,如果验证通过,它将返回客户端并允许用户使用Angular登录。
当我说使用Angular登录时,它将在cookie中存储用户对象和其他内容。但是,用户仍然可以删除调用后端的JS代码,并返回TRUE(在需要的任何地方),并将用户对象(虚拟)插入到cookie和其他对象(无论需要什么)中并登录。这是一件非常困难的事情,但是它是可行的。在许多情况下,即使花费数小时来编辑/黑客攻击代码,这也是不可取的。
这在单页应用程序中是可能的,其中JS文件不会为每个页面重新加载。为了减轻被黑客攻击的可能性,我们可以使用缩小的代码。而且,我想如果像Django中的后端操作(如登录)这样做,它会更安全。
如果我错了,请纠正我。
我会使用缩小和AJAX的组合。如果所有的函数和数据都没有加载到页面中,那么作弊就更加困难了。
另一方面,像Id Software这样的公司发现modding是一个非常有利可图的工具。也许允许系统被修改可能会使游戏对整个社区更加有趣。