Security For Open Source Web Projects? 105
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?"
Depends... (Score:3, Interesting)
If you have the resources, you can always hire someone who might know more about it. If not, you could try relying on people's goodwill, and tell them upfront that "I need help with security".
Finally, didn't Google develop a system to test web application security? I'm pretty sure there was a story about it on Slashdot. There may be other solutions out there that will help you to at least plug the most obvious holes.
Disaster Planning (Score:5, Interesting)
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)
just assume you will fail (Score:4, Interesting)
Assume your server will be rooted. Minimize the damage that can be caused, and maximize the information you can get to defeat the next attack. So:
Have everything backed up to something physically separated from the target.
Have lots of logging to analyze in the event of an attack.
If you have other more conventional stuff you want to keep up, have a spare server with everything minus the game ready to switch in after an attack.
Speaking from 10 years ago (Score:5, Interesting)
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.
Re:Never trust the client. (Score:2, Interesting)
Virtually all big FPS games perform "lag correcting" hit detection on the server against non-current positions (i.e., at time X when player Y fired at player Z). X is determined by the server based on player Y's known latency. This is why you see things like a player dying _after_ rounding a corner. I think this technique was invented by Dynamix (who founded GarageGames).
This is my approach (Score:1, Interesting)
I trust nothing the user sends
I trust nothing the user sends
I don't trust the SAs as I was one
I dont trust the NAs as I was one
I don't trust the DBAs as I was one
After I have all the functionality I need
My to do:
I keep everything sensitive _encoded_ to increase effort (not encrypted, performance for the end user is balanced against the privacy)
I dont keep logs or any information not needed as an attacker can use those logs against you, the system and the users (contrary to what other posters said)
I try to avoid having personally identifiable information of the users, it is not needed unless the user needs it
I seek to separate any information which may betray my user's identity from their actions in the event of a compromise event, you might know the who, but not the what or the what but not the who
my marketing does not require information on users in particular, but only in aggregate, I will collect more average revenue on an aggregate basis and avoid the creepy factor
my goal is only to make it a severe pain in the ass, not to stop them, as any motivated attacker is unstoppable