Socket.io,安全和多人游戏

Per*_*fix 1 security node.js express socket.io

我正在制作一个在线游戏,我想知道Node.js和socket.io的安全性.

目前的比赛状况

我所有的

io.sockets.on('connection', function (socket) {
    socket.on('request', function (data) {
}) });
Run Code Online (Sandbox Code Playgroud)

是安全的.玩家可以发出任何请求(请求在此示例中称为"请求")与任何数据(指"数据"),即使他们手动修改了他们发出的请求和数据,也无法对其进行优先处理并绕过客户端基本安全.他们也无法通过发送内部数据来使服务器崩溃.

注意:我只有2个发射:发射用户/通过登录和发射输入.服务器通过各种'emit'发送数据.会话()或GET/POST没有"通常"的概念.在客户端,我只使用

 var socket = io.connect('http://something:3000');
 socket.emit('request', data);
Run Code Online (Sandbox Code Playgroud)

对于玩家获取代码+图像所需的静态资源,它看起来像:

 app.use(express.static(__dirname + '/public'));
Run Code Online (Sandbox Code Playgroud)

对于数据库:

 client = mysql.createConnection({  host: 'localhost',  user: 'root',   password: 'something',});
 client.connect(); client.query('USE dbname'); 
Run Code Online (Sandbox Code Playgroud)

最后是路由?,无论请求如何,我都会显示相同的页面:

 app.get('/', function (req, res) { 
      res.sendfile(__dirname + '/index.html'); 
 });
Run Code Online (Sandbox Code Playgroud)

关注:

  • 有人可以通过其他方式访问我的数据库而不是发出注射吗?
  • 有人可以修改每个人加载的静态资源吗?
  • 有人可以访问整个服务器脚本或以某种方式修改其变量吗?
  • 有没有办法限制一次发送的最大并发连接数和最大数据量?
  • 我需要任何安全模块吗?
  • 您认为合适的任何其他问题.

非常感谢.

mok*_*oka 6

关于你现在所拥有的 - 一切看起来都很好.除此之外,您不使用消息名称,而是将所有内容修补到request消息中.不要认为这是好方法,并且没有安全理由我可以看到这样的决定背后.您还可以订阅和取消订阅不同的套接字消息 - 这样可以更轻松地管理请求点的"可见性".

您可以通过两种方式查看应用程序的安全性:

技术
它涉及您的服务器,数据库凭据,防火墙,文件权限,域名和其他位的设置,这些不是直接来自应用程序本身.
您关注的是确保访问服务器并不容易,并且修改文件更加复杂.虽然在任何情况下都存在风险,即使是最受保护的.
可靠的托管服务(这里的云是最安全的imho).
访问服务器的凭证 - 也必须得到保护.即使有人会得到这些,仍然需要他们一些时间来进入您的服务和数据库.有能力抵制这个(防火墙,ftp/ssh设置等).

逻辑
这种安全性观点专注于您的应用程序逻辑和以某种方式克服它的能力.
虽然这是一个很大的话题,你可能想读一些关于那个的书.
最简单的考虑因素是对架构方式的一些通用规则.例如:

  • 只有服务器做出决定.对于游戏来说尤其如此.
  • 根本不要相信客户的决策.信任 - 导致作弊.这对服务器来说是更多的工作,但为了防止作弊,它的工作量减少了.因此,尽早开始在"询问客户"和"决定服务器"之间进行正确的"政治"互动.
  • 验证一切,并在出现非常错误的服务器时抛出错误/断开连接.
  • 记录但仔细记录(不要写入文件的所有内容 - 这可能会导致安全问题,特别是如果你使用一些基于html的日志系统,你可以通过http请求注入JS)是潜在的危险.
  • 没有eval以往任何时候都在服务器端.
  • 密码哈希 - 用于密码和其他东西.同时保护你的'盐'和'香料':D.因此,即使侵入您的数据库,也不会允许任何人轻松访问密码.
  • 使用会话来存储数据.Sessions将帮助您将来横向扩展您的应用程序,因为限制一个进程并将内容存储在内存中 - 是高效的,但不可扩展.
  • 身份验证 - 使用可靠的方法,可能是SSL(WSS,HTTPS).
  • 知道你使用什么 - 这有助于尽可能地防止模块的意外行为.
  • 知道它是如何工作的 - 例如使用会话 - 你需要知道识别机制如何工作(cookie等),以及如何存储会话数据(内存,数据库,redis等)