Security For Open Source Web Projects?

PoissonPilote writes "I'm currently developing a multi-player, browser-based game, using the good old HTML, JavaScript, PHP, and MySQL combination. Progress is good so far, and the number of players is slowly but steadily increasing. At the beginning of the project, I decided to put the entirety of my game under the MIT license, so that anyone could study the code or even start their own server for the game. However, with the increasing popularity of my project, I am starting to worry about security issues. Even though I consider myself decent at web development and am pretty sure I'm not making any classic mistakes (SQL injection, cross-site scripting, URL forgery, etc.), I am no web security expert. I didn't find any relevant examples to compare my game to, as most open source games are written in a compiled language, and no web server is at stake in those cases. Some web developer friends told me not to release the source code at all; others told me to release it only when the game will be shut down. Naturally, I'm not satisfied by either of these solutions. What approach would you recommend?"

Comments

Never trust the client.

[Nadaka]

The entirety of the game state should be stored on the server and all user inputs should be validated on the server.

This won't stop people from botting your game, but it will keep the major chunk of blatant cheating to a minimum (at least on unmodified servers).

Security through obscurity

[PrecambrianRabbit]

Closing the source does not make security holes go away. It may make them *marginally* harder to find, but probably not much harder for experienced attackers. What closing the source does do is make it harder or impossible for people who know something about securing such things to help you.

A few things

[raddan]

• Never pass unvalidated input to your database
• Never pass unvalidated input to the system
• Always validate on the server-side; client-side validation should only function as a convenience to the user
• Validate data coming from other servers (if you're doing any web services stuff).
• Encrypt connections to the server
• Enforce inactivity timeouts
• Do not allow multiple logins to the same account (unless you want your game to application to work that way)
• Always authenticate users; consider using two-factor authentication (CAPTCHA + password, etc)
• Allow administrators to revoke accounts
• Make it easy for administrators/force administrators to sandbox/chroot your application
• If your applications needs to use server storage, consider DoS attacks (a user uploading lots of stuff)
• Make sure all privileged actions hit the same authentication class/function; if you change your authentication code, this ensures that the changes are applied across the board <-- I catch newbie programmers making this mistake all the time!

If you do all of the above, your app might still not be "secure", but breaking it will be a PITA.

Start with Linux Intrusion Detection System (LIDS)

[PatPending]

For a start, consider using LIDS

(The name is a misnomer because it prevents alteration of protected components (even as root).)

What to do when a vulnerability is found?

[TSHTF]

I highly recommend you read the announcing security vulnerabilities section of Producing Open Source Software book. You'll probably want to read the whole thing, however!