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?"
Solution: (Score:5, Funny)
Use VB 6.0 MS-SQL Server 2000 and IIS 5.0, can't go wrong there.
Re: (Score:2)
No need for IIS 5.0 MS PWS should work fine and with enough security there....
Re: (Score:2)
Re: (Score:2)
He got the idea from the joke that just went WOOSH over your head.
Re: (Score:2)
How would using a different platform for the server solve all of his problems? Every platform has similar problems; there's no "turn-key" substitute for knowing what you're doing.
My advice: don't release the source. If the application is secure, release it. If it's riddled with vulnerabilities, releasing the source code will only cause headaches for you (and your players). Good choice on a permissive license though. ;)
Re: (Score:2)
How would using a different platform for the server solve all of his problems?
He was being sarcastic.
Re: (Score:2)
Congrats. By using mysql_escape_string, rather than the correct function mysql_real_escape_string, you have just opened your hypothetical site up to SQL injection.
PHP should have fixed mysql_escape_string in place, and those few people whose sites would break as a result told too bad, you should not have relied on broken behavior.
The changes anybody relying on the broken behavior would need to make would be trivial, and it would prevent countless new PHP developers from using a dangerously broken function t
Re: (Score:2)
You shouldn't use either of them directly, as you are opening yourself to potential maintainability hell in future, especially if new vulnerabilities are discovered which do not provide turnkey solution.
Use an DB abstraction layer, an SANE layer, not an stupid one like AdoDb (which is bloated, and does not provide sane abstraction, ie. not intended fully to make it easier for the programmer)
Rails 3 goes to the bin of stupid abstractions, just like CakePHP. While these both provide inexperienced, novice "pro
Re: (Score:2)
Nothing will remove the need to know what you are doing, but having safe defaults, such as defaulting to printing strings escaped, requiring explicit action to print the raw input, helps a lot.
The idea is any decent developer will stop and ensure that the data printed out raw is in fact safe. It might be that it was a template file read in from the source directory, which is probably safe, especially if the server process has only read only access to that directory. Or perhaps the data has been sanitized so
Re: (Score:2, Informative)
Re: (Score:2)
And you've suggested that "peter" and "paul" are a good idea to use as column names.
No, you don't build a framework for any one thing. Even if you decided that an ORM is a good thing -- and it is, for reasons other than security -- that's just one piece.
But see, it's not just SQL injection. It's SQL injection, session management (scalability, protection from forgery), cross-site request forgery protection, cross-site scripting protection (have you escaped all your output?)... combined with, how many times h
Re: (Score:2)
and CakePHP is absolutely the worst thing you can ever do to your app, to yourself or to your sanity.
I've had the unfortunate event of inheriting an CakePHP application. At first CakePHP seemed awesome for getting stuff done quick, but after looking at the source, it was full of hackery gluey code to bypass abstractions to make certain things happen. The original developer did not make the sanest choices either so that didn't help, but the point was clear, for somethings it was hard to make it flex.
I develo
Re: (Score:2)
What Rails does isn't terribly difficult to figure out.
Even if it was, I'm not sure how much it matters to me. I don't muck around in the framework often (though it's not bad), but I do like it when my application code is pretty -- in particular, I like it to say what I want it to say, as much as possible.
Re: (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 no
Re: (Score:2)
This is the wrong way to go about things. Don't move to a technology because it protects you from making silly mistakes.
That isn't what I was suggesting. I'm saying that you should move to a technology because it makes it easier to do things the right way, not necessarily because it makes it harder to do things the wrong way.
For example, many people argue against Ruby because it's possible to do things like this:
This tends to crash the interpreter. But why would you ever do that? It's not about keeping bad/evil/clever programmers at bay, that should be HR's jo
Re: (Score:2)
PHP has good frameworks, and comes with a decent framework to start with. It's not a good comparison to compare a language to a framework, and attacking the language for the lack of a framework, while framework is a framework. That logic fails
PHP inc. PEAR which comes with tons of functionality, hard to search tho and mostly legacy code. Then there are Zend Framework, Symfony, CodeIgniter, CakePHP along many others, with varying degrees of freedom, code quality, abstraction.
Maintainability and Security both
Re: (Score:2)
comes with a decent framework to start with.
What does it come with?
It's not a good comparison to compare a language to a framework, and attacking the language for the lack of a framework,
The problem is, once you add a framework, PHP loses every last advantage it had over a real language. It becomes bigger and slower (so, may as well use Rails), and it's no longer something that everyone just knows with no training (so, may as well use Rails).
PHP is not inherently unmaintainable,
To the extent that a language can be unmaintainable without trying, I think PHP is about the worst out there. I'd again draw an analogy to C -- you can make a good Web framework in C, and you can write good, maintainable web apps
Re: (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.
Re: (Score:2)
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.
You're welcome to make the point that PHP is adequate (although I don't share that view), but please, you're not doing yourself any favours by including Facebook and Joomla in that list. Joomla especially is an outstanding case of Cargo Cult development [wikipedia.org]. Read the first sentence of the linked section and tell me it's not true of Joomla.
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).
Re: (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 wi
Re: (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).
Re: (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'r
Re: (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
Re: (Score:2)
No there is no such trick.
Any game state you store on the client in encrypted form will either require the client to have a key to decrypt it, defeating the security you want. Or it will be inaccessible to the client and will have to be retransmitted to the server with every action, and that defeats the purpose of having it on the client in the first place.
Re: (Score:2)
You're both right.
You are right: there is no such "trick" in the sense that there's not really anything to be gained by storing swathes of game state client-side.
He is right: presuming you implement your crypto correctly, you could (in theory) store bits of game state client-side without the fear of tampering by cheaters.
I'm afraid I can't see any real benefit in doing so -- it seems like a lot more trouble than it's worth, and I'm not sure it's a good solution to any problem -- but you could certainly do i
Re: (Score:2)
Wrong. He's talking about crypto *signing*, not encryption.
Alice is playing Bob's game, and storing some game-state data. Bob signs the data with his private key, and Alice can read the data no problem. But were she to modify it, the signature would no longer be valid (which anybody can check) and the state would be re-downloaded.
The game state isn't a secret, it just needs to be invalidated if modified. Signatures are perfect for this, just sign any changes that your server accepts.
Re: (Score:2)
My point: store all state on the server, validate all user input.
His point: you don't have to store all state on the server, you can store some on the client if it is signed and you don't have to validate the input.
I get that, and its wrong.
1: there is no way to fix invalid state if the client is the one storing the state and not the server. This goes to my original point, the server must store all state and ensure that every request is valid.
2: The context is a multi-player browser based game. Yes, some as
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.
Re: (Score:1)
Just remember the environment (Score:2)
If you pay a qualified expert, they ought to be able to point you in the right direction. I would want to meet them physically though.
That story you mention sounds like the Jarlsberg one. The idea is you learn to secure your web application by exploiting a demonstrably weak one, so you learn your lesson. If you have the time, I definitely recommend working through it all. (story [slashdot.org] Jarlsberg homepage [appspot.com])
Another area to look at is simply your web server configuration. Your web application never runs in isolation.
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.
Re: (Score:2)
also <?php include("security.php"); ?>
Re: (Score:2)
Yeah ... I wouldn't want to use anything you've done...
Re: (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: (Score:1, Offtopic)
Useless you say? When the server gets rooted and will have to be reinstalled from scratch it won't seem as useless.
Re: (Score:1)
Re: (Score:2)
write log files to a dedicated partition maybe?
Re: (Score:2)
Doesn't help if whatever writes is compromised.
Sending over the network to some dedicated server which allows only appending to the log, and no other access from that particular network (management network only, or from a whitelisted list of servers) is definitely secure. Even better if 2 of such hosts are used where another is in another network completely, and automatic cross comparison are they the same :) (Just make sure their logs are exactly synced)
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.
Re:license has nothing to do with security (Score:4, Funny)
They had PowerPoint slides and everything so they knew what they were talking about!
No sir! Closed obfuscated source for me!
Re:license has nothing to do with security (Score:4, Funny)
$ grep vulnerability *.c | wc -l
0
Everything seems fine here to me...
Re: (Score:1, Informative)
$ grep -c vulnerability *.c
Security through obscurity (Score:5, Informative)
Re: (Score:1, Redundant)
Re: (Score:2)
I run a game with a nearly identical setup. I do not reveal my code--not for security purposes, but to maintain the game's secrets. My players have been one of my greatest assets in terms of testing and bug reporting.
Yes, you also occasionally get someone who wants to just game
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)
Securing server, preventing cheating, what? (Score:5, Insightful)
Re: (Score:2)
Each of these has different costs when breached.
Not to mention, different countermeasures.
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.
Re: (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
Re: (Score:1)
I used to run a MUD [wikipedia.org]. This was back in the '80s.
This is actually where I started programming. I learned C and rewrote the codebase from the ground up.
Then, in the 90's I ported it all into PHP to run on the web. This was how I got started in PHP
I haven't worked on it since the 90's, I'm currently a fulltime web developer working in PHP, with all the regular associated technologies: Jav
Two sides of the coin... (Score:2)
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.
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.
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).)
What to do when a vulnerability is found? (Score:4, Informative)
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: (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.
Re: (Score:2)
To add to that, I guess magic_quotes_gpc is deprecated in PHP 5.x anyway, so you're right that it's not worth using. But there are settings within php.ini that can help harden PHP, though as I've said, it's absolutely no substitute for well-written code.
Re: (Score:1)
If you decide to go the route and publish your code, you could at least make an effort to set up the infrastructure to handle bug reports and issue reports from those who discover vulnerabilities. As long as you are proactive in following up any reports, people filing security-related bug reports will feel that they are being listened to, and won't be discouraged from reporting again. Because you want to use a MIT licence, there are plenty of free open-source hosting solutions who will be happy to host your
Sounds Interesting Where's the Source Posted? (Score:2)
We could probably have a more detailed discussion looking at the actual source. That's one of the advantages of Open Source. There's some good advice here already, but for what you're doing I would lean heavily on making it as easy and painless as possible to recover from an incident. Let's say you have a major incident.
If you run it all in a VM you'll lose some performance, but you can snapshot it, kill it and ship the snapshot to a local machine for forensics while directing everyone to a "Maintenance in
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 a
Project Name / Location? (Score:2)
While we all appreciate your aversion to slashvertisement, I'm sure some of us would enjoy seeing what you've put together and/or contribute. Since it's in response to an explicit request for the information, can you point us at your project?
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
OWASP Application Security Verification Standard (Score:2)
Use the OWASP Application Verification Standard - this gives you an insight to the controls you need to work on first. A game should be at Level 2B.
http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project [owasp.org]
Don't worry about the language snobs - ANY language and ANY framework can be secured as long as you do the right thing in terms of design. Where you can go wrong is trusting untrustable data - such as that obtained from the browser without first canonicalizing, valida
Web game security 101 (Score:2)
1) First, you have to protect your users. I'd say there are three things to worry about here:
- SQL Injection. "Little Bobby Tables". This one is easy - use bind variables for all sql, and don't -ever- have dynamically interpreted sql with user inputs.
- Cross Site Scripting ("XSS"). This one is harder. If you ever display something to one user that could have been entered by another user, user b can own user a with some html. It's very hard to check for bad html because it can be disgui
OWASP and more (Score:2)
Here are a few pointers, mostly around PHP web app security:
- http://www.owasp.org/ [owasp.org] - the Open Web Application Security Project has a comprehensive list of things to cover - see their http://www.owasp.org/index.php/PHP_Top_5 [owasp.org] (top 5 PHP issues) in particular
- http://www.sitepoint.com/article/php-security-blunders/ [sitepoint.com] Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping
- http://www.phpbuilder.com/columns/ian_gilfillan20050707.php3 [phpbuilder.com] - ensure include fil
The Open Source Perspective (Score:1)
Well, having been an open source developer for almost the 10 years, I know a bit about this. Firstly you need to code as securely as you can. Do the research, make sure you know whats going, and audit your own code thoroughly.
Don't believe no one else is looking, because they are. I've had one person ask me a few innocent questions about my code, then email a back a week later to say I'd passed their security audit just fine. I've also been unlucky enough - just once - to have the full disclosure emai
Minimal Server ... (Score:1)
PoissonPilote contact me (Score:1)
I do security code reviews for PHP/mysql projects in my day job. I like to help with open source projects in my spare time.
Doug