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

Solution:

[Anonymous Coward]

Use VB 6.0 MS-SQL Server 2000 and IIS 5.0, can't go wrong there.

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.

Disaster Planning

[Anonymous Coward]

Disaster Planning has nothing to do with the code base (thought the code can make recovery easier) but it has much to do with security. If you can prevent security breaches with good coding, great but most of us have to suppose that we missed something so being able to deal with problems once they arise is just as crucial as preventing them in the first place.

For example: keep backups (snapshots) of player state on a separate machine unreachable from the webserver. ie the other machine logs into the webserver and copies data out. This way should the unfortunate happen you zap the webserver instance and restore from backup loosing at most the snapshot interval worth of game play. Yes some players will be upset but they won't all be starting over from scratch.

Some times this is called depth or security beyond a crunchy shell, but I like to think of it in terms of the big picture model where great gameplay, security, and disaster recovery are all pieces of the picture and without all the pieces the product is incomplete. (Kinda like Windows not having an ssh command line client, it's not a usable OS for me until I've installed an ssh client)

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.

Speaking from 10 years ago

[ducomputergeek]

I worked on an OSS browser based MMOG in the late 1990's up until 2003 when someone compromised the OpenBSD server it was being hosted on. As many people who play to win the game, there are more who pride themselves on beating the system. And folks take these games way too seriously.

Not only do you have to keep up with security with your programming, you have to keep on top of your system security. Being a good programmer is almost secondary to being a good systems admin as I learned. That means subscribing and reading all the US-CERT warnings that come out, updated to the latest version of PHP/MySQL as security patches are released, and paying attention to any subsystem/process that is running on the server as well making sure that DNS/BIND, Apache, and anything else running is also up to date.

When my system was compromised, it was one of the other system utilities that was the angle of attack. Something I didn't even bother to notice at the time. Not the game or any of the core software that was being used. After 3 years of constantly battling the people trying to beat the system, the 20 - 30 hours of my free time it was taking to manage it wasn't worth the modest revenue coming in so I put the code up on sourceforge and walked away.