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?"
Never trust the client. (Score:5, Informative)
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 (Score:5, Informative)
mod security (Score:2, Informative)
A few things (Score:5, Informative)
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) (Score:4, Informative)
For a start, consider using LIDS [lids.org]
(The name is a misnomer because it prevents alteration of protected components (even as root).)
Re:Never trust the client. (Score:3, Informative)
That's pretty much the best advise you can get — never trust the client. But as with everything in technology, there's no silver bullet. You also need to consider what you're passing back from the client, try to pass as little as possible, the less you pass back, the less you need to validate and the less chances you have to make mistakes. Also consider what form the data you're passing the data back from the client is in... validating integers is trivial, validating freeform text (especially if you're going to be displaying it somewhere on a page!) isn't.
In the case where you are displaying freeform text from the user (and you'll be hard pressed to avoid this), there are a lot of security problems you need to consider. Ultimately, if you don't let the user use HTML (ever), you can avoid basically all of them, though there's other issues (users pasting very long "words" to break your layout, but that's only a nuisance, not a security problem). If you do let users use HTML (for anything), you need to consider XSS [wikipedia.org] and CSRF [wikipedia.org] (though it need not be cross site).
Basically, read more, and always be thinking about security when you're adding new functionality that takes user input. It's really not that difficult to do, you just need to be aware of the issues. I've done almost exactly the same thing with Game! [wittyrpg.com], it's not open source, but that really doesn't change any of the security issues.
Re:license has nothing to do with security (Score:1, Informative)
$ grep -c vulnerability *.c
What to do when a vulnerability is found? (Score:4, Informative)
Re:Never trust the client. (Score:3, Informative)
AFAIK, FPS games are precisely the ones that don't trust the client at all. They just send commands to the server and receive state updates; any simulation that happens on the client side is entirely for prediction (i.e., aesthetic) purposes.
It's RTS games that tend to trust clients more, simply because of the extremely large game states involved. These often run deterministic simulations for all players, and exchange user inputs. Cheating is ameliorated here because any modification to the game state will cause the two players to get "out of sync," but maphacks are hard to avoid with these sorts of implementations. See e.g. this article [gamasutra.com]; it's not exactly new but AFAIK this is still how things are done.
Re:just assume you will fail (Score:3, Informative)
I'm with this guy. If you can afford to, separate the web tier and the database tier physically. Provide extra layers of security on essential stuff at the database tier (additional validation via procedures, etc). Make sure the app keeps a secure write-once log of every transaction that occurs for all players. I'd direct that off to another machine as well, if you can.
You might remember some time back that there was a case where EVE players found a way to essentially cheat to create more resources than the game normally allows (they found out that certain factories would keep getting raw material, even though the material was actually being sent to a different factory, for as many factories as they performed the same trick) the EVE people essentially figured it out, and then rolled back all of the in-game corporations to erase the money made. Something like this is only possible with full logs of every item created and used up and the flow of resources throughout the system.
Re:Never trust the client. (Score:2, Informative)
Actually, there's a really nifty trick you can do: make the client store your data for you, but signed with your key. That scales cleanly with the number of clients and keeps the security.
You can expect that if people are going to get the source code, then they're going to set up their own instances and then run a standard web security scanner on it. You can do that first. Skipfish [google.com] will hammer on your site though you get to read piles of documentation to use it. Ratproxy [google.com] has the same idea except that it acts as a transparent proxy while you use your site, and has very little setup.
If you're serious about web app security, look at Jarlsberg [appspot.com]. It's not a tool, it's a lesson.
Re:I'll bite. (Score:2, Informative)
Re:Game or not, web app security is web app securi (Score:2, Informative)
"LGPL-licensed pure-PHP implementations of an arbitrary-precision integer arithmetic library, fully PKCS#1 (v2.1) compliant RSA, DES, 3DES, RC4, Rijndael, AES, SSH-1, SSH-2, and SFTP."
Great to have if you're not sure others will have mcrypt or other options installed on their server.