Socket.io, Security and Multiplayer

I'm currently making a online game and I'm wondering about the security of Node.js and socket.io.

Current State of the Game

All my

io.sockets.on('connection', function (socket) {
    socket.on('request', function (data) {
}) });

are secure. Players can emit any request (request refers to 'request' in this example) with any data (refers to 'data') and they won't be able to take avantage of it, even if they manually modify what request and data they emit and bypass client basic security. They also won't be able to make the server crash by sending invalide data.

Note: I only have 2 emits : emitting user/pass to log in and emitting input. The server sends data via various 'emit' though. There's no 'usual' notion of session(), or GET/POST. On client side, I'm exclusively using 

 var socket = io.connect('http://something:3000');
 socket.emit('request', data);

For the static resources that players will need to get the code + images, it looks like:

 app.use(express.static(__dirname + '/public'));

For database:

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

And finally for routing?, I show the same page, no matter the request:

 app.get('/', function (req, res) { 
      res.sendfile(__dirname + '/index.html'); 
 });

Concerns:

  • Could someone access my database by other ways than emitting an injection?
  • Could someone modify the static resources that are loaded by everyone?
  • Could someone have access to the whole server script or modify in a way its variables?
  • Is there a way to limit maximum concurrent connections and maximum amount of data sent at once?
  • Do I need any security module at all?
  • Any other concern you think is appropriate.

Thanks a lot.

Regarding what you've got right now - everything looks totally fine. Apart of that you dont use message names, but patch everything into request message. Dont think that this is good way, and there is no security reasons I can see behind such decision. As well you can subscribe and unsubscribe to different socket messages - makes it easier to manage 'visibility' of request points.

There are two ways you can look at security of your applications:

Technical
It relates to your setup of server, database credentials, firewall, rights to files, domain names and other bits, that are not directly from application it self.
Your concern here is make sure that access to server is not easy, and modifying files even more complex. Although there is always risk in any case, even most protected.
Reliable hosting services (Clouds here are most secure imho).
Access credentials to server - have to be secured as well. Even if someone will get those, still it should require them some time to get into your services and database. Have ability to resist this (firewall, ftp/ssh settings, etc).

Logical
This point of view on your security focuses specifically on your application logic and ability to somehow overcome it.
It is big topic though, and you might want to read generally some books about that.
Simplest things to think about is some generic rules over the way you architecture. For example:

  • Only server makes decisions. This is especially true for games.
  • Do not trust client in decisions at all. As trust - leads to cheating. It is more work for server, but it is less work after in order to prevent cheaters. So start early with right 'political' interactions between 'asking clients', and 'deciding server'.
  • Validate EVERYTHING, and throw errors/disconnects when something very wrong comes to server.
  • Logging but carefully (don't write to files everything - that might lead to security issues, especially if you use some html based log systems, you can inject JS - through http request - is potentially danger.
  • No eval ever on server side.
  • Password Hashing - for passwords and other stuff. As well keep secure your 'salts' and 'spices' :D. So that way even breaking into your database, will not allow anyone to access passwords easily.
  • Use sessions to store data. Sessions will help you in the future to scale your application horizontally, as limiting to one process and storing stuff in-memory - is efficient, but not scalable.
  • Authentication - use reliable methods, possibly SSL (WSS, HTTPS).
  • Know what you use - this helps to prevent unexpected behaviour of modules as much as possible.
  • Know how it works - for example with sessions - you need to know how identification mechanism works (cookies, etc), and how session data is stored (in-memory, db, redis, etc)