有什么好方法可以防止JavaScript多人游戏中的作弊?

有什么好方法可以防止JavaScript多人游戏中的作弊?,javascript,security,multiplayer,Javascript,Security,Multiplayer,想象一个具有滚动级别的太空射手。有哪些方法可以防止恶意玩家修改游戏以使其受益?他能做的很难限制服务器端的事情是自动瞄准、在可见区域外偷看、加速黑客攻击和其他事情 有什么方法可以防止这种情况?假设服务器是任何语言,并且客户端通过WebSocket连接 始终假设代码是100%可黑客攻击的。想办法防止完全重写的客户机(为了作弊)作弊。这些可以是编写安全游戏协议、服务器端检测等的方法。您无法阻止任何人修改JS或编写GreaseMonkey脚本。然而,你可以通过缩小你的脚本以及使你的代码尽可能的神秘来让他

想象一个具有滚动级别的太空射手。有哪些方法可以防止恶意玩家修改游戏以使其受益?他能做的很难限制服务器端的事情是自动瞄准、在可见区域外偷看、加速黑客攻击和其他事情

有什么方法可以防止这种情况?假设服务器是任何语言,并且客户端通过WebSocket连接


始终假设代码是100%可黑客攻击的。想办法防止完全重写的客户机(为了作弊)作弊。这些可以是编写安全游戏协议、服务器端检测等的方法。

您无法阻止任何人修改JS或编写GreaseMonkey脚本。然而,你可以通过缩小你的脚本以及使你的代码尽可能的神秘来让他们难以理解。甚至可能加入一些假的方法或变量,这些方法或变量什么也不做,只是用来赶走攻击者。但是如果有足够的时间,这些方法都不是绝对可靠的,因为一旦你的代码进入客户端,它就不再是你的了。

它们不必接触你的客户端代码——它们可以嗅探并实现你的Websocket协议,然后编写一个伪装成人类玩家的微型代理

更新:这个问题有几个部分,我脑子里没有现成的答案,但是可以考虑以下问题来评估各种选项:

  • 为了防止作弊,你愿意走多远?如果你只关心偶然的作弊,有多少障碍足以阻止偶然的作弊者?中级Javascript程序员?一个严肃的专家?权衡这一点和作弊的好处,是否有任何真正有价值的东西处于危险之中,比如现金和奖金,或者仅仅是声誉
  • 你如何获得一个高度的信心,一个人正在为你的游戏提供输入?例如,有了一个足够好的计算机视觉库,我可以在一台单独的机器上为你的游戏建模,将输入假装成鼠标输入计算机,但这相对成本很高(不值得我花时间)
  • 如何在协议中创建信任链,以便将(2)的知识传递给服务器,并且服务器对客户端代码发送消息相对有信心

  • 当然,你扔下的很多路障都是可以绕过的,但是对球员和你来说,代价是什么呢?请参见“

    我将使用缩小和AJAX的组合。如果所有的函数和数据都没有加载到页面中,那么作弊就更难了


    另一方面,对于Id软件这样的公司来说,modding是一个非常有利可图的工具。也许允许对系统进行修改可能会让整个社区对游戏更感兴趣。

    我甚至可以考虑实现这一点的唯一方法是修改Javascript以作为客户端,然后设计一个中央服务器机制来验证从该客户端发送的数据。这可能是一个需要实施的重大变更,很可能会使您的项目更加复杂。但是,正如前面所说的,如果应用程序完全在客户机上运行,那么客户机几乎可以对脚本执行他们想要的任何操作。确保其安全的唯一方法是使用受信任的计算机来处理验证。

    服务器为王。客户端是可黑客攻击的

    你想用你的websocket做两件事

    向服务器发送游戏操作并从服务器接收游戏状态

    渲染游戏状态。然后将输入发送到服务器

    • 自动瞄准-这个问题很难解决。你必须追求现实主义。如果一个用户在10秒内点击了10张头像,你就踢他。写一个聪明的作弊检测算法
    • 窥视可视区域外-仅将可视区域发送给每个客户端即可解决此问题
    • 加速黑客攻击-通过正确处理输入来解决。您收到一个事件,用户a向前移动,您可以控制他移动的速度
    您无法通过缩小代码来解决这些问题。客户端上的代码仅用于处理输入和显示输出。所有逻辑都必须在服务器上完成

    您只需编写服务器端验证。唯一的问题是,由于复杂性,游戏输入比表单输入更难验证。这与确保表单安全的方法完全相同

    不过,您需要对“输入有效”检测非常小心。你不想踢/禁止高技能玩家进入你的游戏。很难在机器人检测过于宽松和过于严格之间找到平衡。总的来说,机器人检测的整个领域是非常困难的。例如,“地震”有一个自动瞄准检测系统,可以将那些技术熟练的玩家踢回原处

    至于阻止机器人连接到您的websocket,请直接在多人游戏上设置单独的HTTP或HTTPS验证通道以增加安全性。使用多个Http/https/ws通道将客户端验证为“正式”,充当某种形式的握手。这将使直接连接到ws变得更加困难

    示例:

    想象一个简单的多人游戏。一款基于2D房间的赛车游戏。多达n个用户在平面2D平台地图上竞相从a到B

    假设您有一个万无一失的系统,其中通过HTTPS通道进行复杂的身份验证,因此用户无法直接访问您的websocket通道,并被迫通过浏览器。您可能有一个处理身份验证的chrome扩展,并强制用户使用它。这减少了问题的范围

    服务器将发送客户端渲染屏幕所需的所有可视数据。你不能掩盖这些数据。无论你尝试什么,一个愚蠢的黑客都会拿走你的代码,然后放慢速度