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?"
sandbox it maybe? (Score:5, Insightful)
Probably you want to sandbox your webserver, put it into a VM, run it as some user other than root obviously, have a HW or OpenBSD/PF based firewall sit in front of it and redirect requests to your VMs network, make sure no other services are running that can be accessed from the outside excluding the VM, probably add SSL to it (we just had a discussion on self signed certificates [slashdot.org] a little while ago here and what kind of POS it is to work with browsers in that case). I mean, it's a game, nobody is going to point and laugh at you if it has some web security issues, but you are not exactly explaining your architecture here either, you probably would be better off sandboxing it into a VM like that.
license has nothing to do with security (Score:3, Insightful)
Don't make the mistake of thinking that obscurity (that is, making your code secret) guarantees security.
Also note that there are very secure projects (such as OpenBSD) which are released under the MIT license.
Securing server, preventing cheating, what? (Score:5, Insightful)
Re:Sounds like troll bait (Score:3, Insightful)
Right, that's why there are no serious projects written in PHP.
Except for Facebook, Wikipedia, Yahoo!, Digg, Joomla, eZ Publish, WordPress, YouTube in its early stages, Drupal and Moodle, and thousands others.
Game or not, web app security is web app security (Score:5, Insightful)
You got me before my morning (afternoon) coffee so here are some haphazard thoughts:
1) You're writing a PHP/MySQL app. It doesn't matter if it's a game or the next big social networking site. There are holes common to all web apps (check out the OWASP Top 10 [owasp.org]). There are also holes common in PHP code, such as remote file inclusion. There are things you can do wrong with JavaScript. Learn about them, learn about how to prevent them and write your code accordingly. Security should be part of development, not something you tack on afterward. This means using good coding convention (i.e using parametrized queries instead of concatenation, always encoding output, etc) and ensuring that any design decision you make does not compromise the security of your application. Make sure security is multi-layered as well. For example, even if you think your app is 100% free of SQL injection (wrong assumption!), you still need to make sure you've properly hashed user passwords in the database in case they're exposed. (Side note: please don't use MD5 for this; look into bcrypt, or at least many rounds of SHA-256 or such.)
2) Harden your environment. No amount of hardening will stop all attacks, but it may help mitigate their impact, and if you're lucky, it may thwart some script kiddies or automated scripts. Running PHP? Harden the crap out of your php.ini (magic_quotes_gpc, turn off fopen() for URLs, etc). Think about installing the Suhosin patch [hardened-php.net]. Just don't get complacent; there are ways around all these protections and they are not a substitute for secure code! You may also consider a web-app firewall (WAF), in the vein of mod_security, but don't fully rely on these either. If you're publishing code for others to use, don't ever count on your users to implement these same protections in their environment.
3) Web app scanners can help, especially if you're a novice with security, but once again, they will not catch everything (probably not even a lot of things.) There's skipfish, NetSparker and free versions of some of the more commercial scanners.
4) I know your question was whether to publish your code. I say "Yes", but this is a personal opinion -- I just happen to think it will give security dudes more of a chance to audit your code, and attackers will find your vulnerabilities anyway, through poking at your app and fuzzing even if nothing is published.
I hope that helps a little!
Re:sandbox it maybe? (Score:1, Insightful)
Useless. You are completely missing the point. The problem is protecting the security of the PHP webapp - good luck with that - not preventing attacks against other services.
Re:I'll bite. (Score:3, Insightful)
Seconded.
I was part of a team coding and maintaining one of those classic apps that went straight from proof-of-concept to production (much to our chagrin). I'll never forget the time a security advisory was released for PHP and, when we found 4 other vulnerabilities in the same section of code (a single function), we were first told that they weren't relevant to the immediate fix and then that these were 'only' DoS bugs, therefore not security vulnerabilities.
I campaigned for months to get the manpower to refactor the application in a Real Language (which had been the plan, at some stage), but by then we had several months of work invested and about 50,000 lines of code committed. Management expressed their sympathy and said, effectively, 'Not a chance.'
Given that you are Management in this case, I'd urge you not to make the same mistake we did.
This is the wrong way to go about things. Don't move to a technology because it protects you from making silly mistakes. Choose a technology that fits you best, factoring in security as one aspect of its overall performance. And even when you choose a language/framework that offers protections like those above, you're still not exempted from checking your inputs and outputs. No matter what language you choose, you still need to secure your code base. If the language offers you nice hooks to do it with, so much the better, but that should never remove your obligation to think through what happens to every byte your app handles.
attack prevention? what about detection, recovery? (Score:1, Insightful)
Security solution doesn't need to mean zero vulnerabilities. In addition to preventing attacks, you should focus on detection and recovery aspects.
Assume you will be attacked, will you be able to notice it? Write statistics systems to display player progress over time (or income per day, etc) and make sure you can spot unusual cases. Keep logs of events to track down what exactly happened so you can figure out how the suspicious players did what they did, etc...
Also, something will go wrong eventually. Can you do full rollback of one day or two? What will players think of it, how can you compensate for the time your players lost? Imagine someone hacks your database and changes stuff, can you track the propagation of the damage? If someone illicitly made millions of in-game cash, where did that go to? Etc etc...
You cant stop all attacks, so focus your effort on other aspects of risk management.