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.

Never trust the client.

[Nadaka]

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:Never trust the client.

[Mad Merlin]

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 and CSRF (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!, it's not open source, but that really doesn't change any of the security issues.

Re:Never trust the client.

[TerranFury]

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; it's not exactly new but AFAIK this is still how things are done.

Re:Never trust the client.

[Anonymous Coward]

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:Never trust the client.

[Anonymous Coward]

The entirety of the game state should be stored on the server and all user inputs should be validated on the server.

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 will hammer on your site though you get to read piles of documentation to use it. Ratproxy 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. It's not a tool, it's a lesson.

Depends...

[hkmwbz]

That depends a bit on your resources, now doesn't it? Is it just a game you are working on as a hobby? Or are you expecting to commercialize it and make money? Do you expect a lot of users, or is it just something for your friends and acquaintances to play?

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.

sandbox it maybe?

[roman_mir]

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 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

[Anonymous Coward]

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

[AnonymousClown]

Oh please. I took the special PHB IT security class and they told us how Open Source allows the bad guys to see all the APIs that allows one to break in. Such as: BreakInThoughTheBack, SQLInjectTion, GetAroundEcrytpion, and ReplaceLegitimatCodeHere classes.

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

[PrecambrianRabbit]

$ grep vulnerability *.c | wc -l
0

Everything seems fine here to me...

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)

Securing server, preventing cheating, what?

[noidentity]

You didn't make clear what you were trying to secure in the first place. Are you securing against someone doesn't exploit your game in order to get control of the server itself? Are you securing against someone cheating within the game? Securing user data from tampering? Each of these has different costs when breached.

just assume you will fail

[Surt]

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:just assume you will fail

[ashridah]

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.

mod security

[voot]

i would definitely check out mod security. it has injection detection which is good for any web application and a open source one is no different.

Re:Sounds like troll bait

[Anonymous Coward]

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.

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.

Start with Linux Intrusion Detection System (LIDS)

[PatPending]

For a start, consider using LIDS

(The name is a misnomer because it prevents alteration of protected components (even as root).)

What to do when a vulnerability is found?

[TSHTF]

I highly recommend you read the announcing security vulnerabilities section of Producing Open Source Software book. You'll probably want to read the whole thing, however!

Game or not, web app security is web app security

[twistah]

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). 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. 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:I'll bite.

[grcumb]

It has to be said: Don't use PHP if you value security or maintainability.

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.

Yes, you can build a decent framework on top of PHP, so that you won't be vulnerable to SQL injections. By the time you do, you lose any speed advantage (or "ease-of-use" advantage) PHP had over Ruby on Rails. Given that, if you think Rails is too slow, your only real alternative is something like Java, and I'm not even sure Java with a full stack is any better.

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.

Re:I'll bite.

[larry bagina]

aside from the mysql_escape_string()/mysql_real_escape_string() issue, you should be using PDO and prepared statements instead of building sql queries. Less work, easier maintenance, better security, better performance.

Re:Game or not, web app security is web app securi

[Daem0nX]

For encryption check out http://phpseclib.sourceforge.net/
"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.