Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Security For Open Source Web Projects?

Soulskill posted more than 4 years ago | from the get-your-hands-on-some-military-level-ice dept.

Security 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?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Solution: (5, Funny)

Anonymous Coward | more than 4 years ago | (#32709816)

Use VB 6.0 MS-SQL Server 2000 and IIS 5.0, can't go wrong there.

Re:Solution: (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32709930)

Use VB 6.0 MS-SQL Server 2000 and IIS 5.0, can't go wrong there.

there's gotta be a nigger joke in there somewhere

Re:Solution: (0)

Anonymous Coward | more than 4 years ago | (#32716028)


Re:Solution: (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32709960)

His he developping another fucking shitty "games" (cuz really its not) where you have to spam your own profile to get stuffs ?

He's the cancer killing webdevelopment.

Re:Solution: (0)

Anonymous Coward | more than 4 years ago | (#32710040)

Where did you get that idea from?

Re:Solution: (1)

Pharmboy (216950) | more than 4 years ago | (#32712390)

He got the idea from the joke that just went WOOSH over your head.

Re:Solution: (0)

Anonymous Coward | more than 4 years ago | (#32712242)

You look lost. 4chan is that way ->

Re:Solution: (1)

JamesP (688957) | more than 4 years ago | (#32710518)

No need for IIS 5.0 MS PWS should work fine and with enough security there....

Re:Solution: (1)

Spykk (823586) | more than 4 years ago | (#32724280)

What do you know, it looks like my manager posts as an AC on slashdot.

Sounds like troll bait (0)

Anonymous Coward | more than 4 years ago | (#32709824)

PHP + Security considerations, this is going to get ugly.

However, I will chime in...

"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.)"

Lets hope so. If you used something else maybe you wouldn't have to be "pretty sure". It will bite you, history shows.

Re:Sounds like troll bait (1)

Peach Rings (1782482) | more than 4 years ago | (#32709936)

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:Sounds like troll bait (1)

PatPending (953482) | more than 4 years ago | (#32710034)

How would using a different platform for the server solve all of his problems?

He was being sarcastic.

I'll bite. (-1, Flamebait)

SanityInAnarchy (655584) | more than 4 years ago | (#32710194)

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

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.

Yes, you need to know what you're doing. The question is whether the platform makes it easier or harder for you to do it right. Rails has built-in countermeasures to request forgery, and even the built-in ORM makes it rare that you have to (or want to) write raw SQL, let alone use string interpolation. HTML-escaping in your templates is a single keystroke, and you can get template engines that make it the default.

That said, depending how much of this game has been written, porting to another language may be out of the question. But let's put it this way: Would you write a web app in a language that makes it possible for you to implement a buffer overflow? That is, would you use C?

Re:I'll bite. (0)

Anonymous Coward | more than 4 years ago | (#32710226)

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

Yes, you can build a decent framework on top of PHP, so that you won't be vulnerable to SQL injections

srsly? just how slow is mysql_escape_string() or htmlentities()*, and why are they so difficult that you'd want to swap technologies just to avoid using them?

* ok so you might wrap this one function to do UTF-8 with less typing, but that's hardly "a framework"

Re:I'll bite. (1)

Tacvek (948259) | more than 4 years ago | (#32710612)

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 that was kept solely for backwards compatibility with already broken apps.

As for why you would want to use a different framework, well in Rails 3 you cannot accidentally open youself to SQL injection, since the idioms for using SQL prevent it. If you really need the unsafe behavior you need to do extra work (not much extra work, but still more than doing things safely).

Similarly you don't become XSS vulnerable by forgetting to escape output. Instead everything output that derives from a source other than framework code (so data from the user, data from the database, etc) is escaped by default. If you have data you know is safe, and need not be escaped, you can explicitly request that the string not be escaped.

Re:I'll bite. (1)

Skal Tura (595728) | more than 4 years ago | (#32713926)

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 "programmers" a chance to create something mostly functional, it does so it by killing flexibility, maintainability and especially performance, since most of the people using these are going to use every single abstraction piece there is, without thinking once what is a sane level of abstraction or a sane abstraction module. Same thing can be done to a degree with Zend Framework and Symfony as well. Besides, Rails 3 is Ruby, not PHP and PHP being the most mature, most supported, most widely used language of choice for web applications. (What did facebook use again? Oh yeah, they even developed their own version PHP, yup that's right!)

XSS vulnerabilities: You still need to know what you are doing, and automated user input sanitization only will mean you rely on that and unsatized input will get past you or even that you are getting yourself into sanitization hell when you need unsanitized input for custom sanitization, you got to run extra loops. Plus you make your code harder to maintain, again.

Nothing will remove the need to actually knowing what you are doing

Re:I'll bite. (2, Informative)

larry bagina (561269) | more than 4 years ago | (#32710804)

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

Anonymous Coward | more than 4 years ago | (#32710544)

Build a framework? You mean this?
        $stmt = $db->prepare('SELECT jim, bob FROM foo WHERE peter > ? AND paul = ?');
        $stmt->execute(array($val1, $val2));

That's literally all it takes to make SQL injection impossible in PHP or any other language (with the appropriate syntax of course). The fact that you think it's necessary to "build a framework" and that such a framework would be resource intensive demonstrates that you are wholly unqualified to comment on web app security or to compare PHP to other languages. Please stop, least someone listen to you.

Re:I'll bite. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32710992)

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 have you written pagination? How many times have you written a login system?

No one needs a framework for any one thing, but when starting with the bare metal, you do tend to find yourself adding one thing after another until you've got a mini-framework of your own -- one which is far less well tested and maintained than an open source one.

I was wrong to say that you need a framework just for SQL injection, full stop.

I was getting my points confused -- I was arguing that PHP is not a good choice for security or maintainability, and SQL injection is one example. I was also attempting to counter anyone's suggestion of something like CakePHP -- if you're going to go the full framework route with PHP, you may as well use Rails.

And "resource intensive" is relative. I don't think Rails is slow, but there is that perception, and if I recall, Cake is slower than Rails.

Re:I'll bite. (1)

Skal Tura (595728) | more than 4 years ago | (#32713948)

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 developed new features, bug fixes etc into it. Somethings were innecessarily hard to make happen with it, so it wasn't that flexible. But the worst thing was that we needed to update it, but it was deemed as too big of a project to update underlying cakephp framework to a new feature because of backwards incompatibility.

CakePHP seems to target inexperienced developers, with absolute rapid development by making everything automated, not that sane solution for highly customized functionality. It had it's good things, such as scaffolding as well. But it was like learning coding from scratch as everything needed some obscure abstraction, documentation wasn't good enough for the task etc. Things which should have been accomplished in 1minute flat, sometimes took 1hour of browsing documentation.

Re:I'll bite. (0)

Anonymous Coward | more than 4 years ago | (#32710626)

Wha? The only options are PHP, Rails, and Java? What about Python? Django [] is a nice web framework with good maintainability and speed but without any of Rail's magic [] (i.e. code that works in a way that is difficult to figure out).

Re:I'll bite. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32710964)

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:I'll bite. (2, Insightful)

grcumb (781340) | more than 4 years ago | (#32710778)

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


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. (1)

SanityInAnarchy (655584) | more than 4 years ago | (#32710938)

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:

class NilClass
  def nil?

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 job. No, you choose a technology because of what you can do with it.

I don't use the Rails stack by itself, generally -- I use DataMapper for an ORM -- but in either DataMapper or ActiveRecord, it's still easier for me to write good, maintainable, SQL-injection-free code than it is for me to do the same in PHP.

even when you choose a language/framework that offers protections like those above, you're still not exempted from checking your inputs and outputs.

That depends what they're being used for. If you stick to a framework which is mostly designed for storing data, there's not much to check -- just use the data as, well, data, and you're not vulnerable.

It's the weird edge cases that keep cropping up, like clickjacking, but that's hardly about "checking inputs and outputs". So I agree with this statement:

No matter what language you choose, you still need to secure your code base.

I just don't think it means "checking inputs and outputs".

Re:I'll bite. (1)

Skal Tura (595728) | more than 4 years ago | (#32714016)

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 are functions of programmer skill. Unskilled programmer will always make low level quality code. Novices will always make novice mistakes.

PHP is not inherently unmaintainable, but sadly most PHP code is unmaintanable. But that does not mean that it has to be unmaintanable, there are plenty of maintainable PHP code around as well, just not very good open source examples. Also security issues with PHP apps has nothing to do with the language, but lack of programmer skill. Just count how many language side security flaws PHP has nowadays... Right at about 0. PHP is also the most widely used, so security issues are found easiest, by being well tested.

Most PHP code you find is legacy, non-abstracted, linearly coded, no OOP, no framework spaghetti relying on globals, global functions, include files and mixing business logic, flow control and visual layer in a garbled mess.

Why a lot of PHP is such a garbled mess then? Low barrier of entry, a lot of complete newbs has been using PHP as their first touch to anything programming. Doesn't mean that a professional developer using PHP is prone to same errors as those complete newbies to programming. PHP is easy to start with, easy to learn to get something done with (good documentation).

There is tons you can do to make your PHP code maintainable, starting with layer separation (MVC), sensible code quality metrics (General size of classes, functions), and choosing the "framework" which gives good freedom to developer, while making it easier to make well performing, secure maintainable code. All this sums up: Go with experienced developers, who actually think and know what they are doing, and not the novices who don't know what they are doing.

Re:I'll bite. (0)

Anonymous Coward | more than 4 years ago | (#32717524)

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

I'd rephrase that as, "Don't ever start a new project with PHP," but a blanket "don't use PHP" is useless advice. If you're maintaining a large legacy project written in PHP, then that's what you have and you need to learn to live with it, instead of throwing up your hands in resignation.

Your advice is fine if you get a time machine and can go back to the 1990s and reach everyone. Without a time machine, though, it's just pointless. PHP has the same problem as Windows: it's here, and the long-term fix is to slowly replace it as situations where you can get away with it, some up.

Re:Sounds like troll bait (3, Insightful)

Anonymous Coward | more than 4 years ago | (#32710012)

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:Sounds like troll bait (0)

Anonymous Coward | more than 4 years ago | (#32710762)

And that's why Facebook is working in a PHP translator to C++

Re:Sounds like troll bait (1)

grcumb (781340) | more than 4 years ago | (#32711520)

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 [] . Read the first sentence of the linked section and tell me it's not true of Joomla.

Never trust the client. (4, Informative)

Nadaka (224565) | more than 4 years ago | (#32709832)

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. (0)

Anonymous Coward | more than 4 years ago | (#32709896)

Then you still need something to stop bots - assuming someone will bother to write one.

Re:Never trust the client. (0)

Anonymous Coward | more than 4 years ago | (#32710064)

That is not alway a solution.
Games where things happens fast, like FPS, you need to trust the client.

For when a user sees the enemi on the screen and fires.
If you then tell the server that he firet, and the direction, then the person he shot at is not there anymore, and the user will get a miss.

Make things that cheks that the user is not cheating, or trust your users is the only thing you can do.
if you are making a game that is not turn based, or have auto aim (as most mmo games has)

Re:Never trust the client. (2, Informative)

TerranFury (726743) | more than 4 years ago | (#32710306)

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. (0)

Anonymous Coward | more than 4 years ago | (#32714070)

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.

That all depends on the game. I've seen plenty of FPS's which rely on client trust, and others which don't trust the client at all. Same goes for RTS, RPG's, etc. Suffice it to say that any game which trusts anything the client sends the server WILL be hacked (assuming it gets popular enough and long enough for anybody to care to try).

If you want a perfect example of "Don't try doing things this way" look up the history of the Phantasy Star Online series from SEGA (starting on the Dreamcast).

The other issue with storing game-state data locally is that it's not tamper-proof, even from a read-only point of view, and state information often contains data which that client should NOT be aware of. For example, many MMO's will load information about other people nearby before your avatar should even be aware they are around... so that there isn't a sudden lag spike when they jump out from behind a tree. The drawback is that if it's a low-traffic area, and I'm just sitting in one spot, I can tell whenever someone comes near me because I can hear my HDD thrash for a second while it loads up the new model data. And that doesn't require me to do ANY hacking of the locally stored data.. I've seen people run programs that will (for example) modify the HUD so that you can "see" any loaded avatar even when they are supposed to be hidden from view.

Re:Never trust the client. (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32710340)

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. (0)

Anonymous Coward | more than 4 years ago | (#32710086)

A CAPTCHA sort of thing might stop most bots but not always.
If its too frequent it will annoy real players.
I've seen one that just played until it got a CAPTCHA then beeped until I clicked it.

Dont allow users to enter any URL for any input.

A few things I've done in the past....

Setting your character image URL to another game URL that will cause them to waste energy/points or buy something (like a stick for 20000 gold).
Setting up a PHP script as your user image that displays the person's IP address on a photo (scares people sometimes) but allows you to collect player IPs and sometimes.
other data.

Re:Never trust the client. (2, Informative)

Mad Merlin (837387) | more than 4 years ago | (#32710106)

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. (2, Informative)

Anonymous Coward | more than 4 years ago | (#32710802)

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.

Re:Never trust the client. (1)

Nadaka (224565) | more than 4 years ago | (#32712146)

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

maztuhblastah (745586) | more than 4 years ago | (#32712882)

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

Re:Never trust the client. (1)

slimjim8094 (941042) | more than 4 years ago | (#32713134)

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

Nadaka (224565) | more than 4 years ago | (#32714664)

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 aspects of game state are likely to be secrets because most multi-player games have state information that is to be hidden from other players (your poker hand, your list of powers, remaining hp, etc).

Depends... (2, Interesting)

hkmwbz (531650) | more than 4 years ago | (#32709838)

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.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32709978)

Or are you expecting to commercialize it and make money?

If he wants to make money at it, he wouldn't open source the code. If it gets good enough for people to pay for it, someone will take fork the code and set up something so that people can play for free and make sure that he can't profit off of his work.

Re:Depends... (1)

Zixaphir (845917) | more than 4 years ago | (#32710096)

Not entirely true, unless every part of the game is FLOSS. I mean, proprietary graphics make this a lot harder to do. Also having the first and original version tends to give you a bit of leeway. And also, you can commercialize with ads in the worst case scenario and not charge anyone a dime.

Re:Depends... (0)

Anonymous Coward | more than 4 years ago | (#32710140)

Open sourcing the code doesn't mean they'll have access to all the graphics assets.

Just remember the environment (1)

improfane (855034) | more than 4 years ago | (#32710230)

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 [] Jarlsberg homepage [] )

Another area to look at is simply your web server configuration. Your web application never runs in isolation. You have databases, web servers, sever side languages and other web applications that you use that are exploitable. Try to do as much checking as you scan for any obvious flaws, use tools to help you.

Run configuration file scanners for Apache [] , PHP*. Although I must stress I have not tried any of these, I just know they exist. I found these by just searching 'php scanner' and 'apache configuration scanner'.

Obviously they do not replace simply being careful or a whitehat's opinion and not trusting tools blindly. (A black hat probably doesn't release all his tools) Also try some generic vulnerability scanners which look for insecure installations that your web host may have installed like web mail and phpMyAdmin.

Just remember the environment.

sandbox it maybe? (4, Insightful)

roman_mir (125474) | more than 4 years ago | (#32709844)

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.

Re:sandbox it maybe? (1)

buchner.johannes (1139593) | more than 4 years ago | (#32709970)

also <?php include("security.php"); ?>

Re:sandbox it maybe? (0)

Anonymous Coward | more than 4 years ago | (#32710222)

also <?php include("security.php"); ?>


Re:sandbox it maybe? (1)

Skal Tura (595728) | more than 4 years ago | (#32714146)

Yeah ... I wouldn't want to use anything you've done...

Re:sandbox it maybe? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32710478)

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:sandbox it maybe? (0, Offtopic)

roman_mir (125474) | more than 4 years ago | (#32710496)

Useless you say? When the server gets rooted and will have to be reinstalled from scratch it won't seem as useless.

Re:sandbox it maybe? (1)

ksandom (718283) | more than 4 years ago | (#32711512)

Something that occured to me as you said this, was VM + external logs. So if the VM gets trashed, you still have a pretty good idea what the last thing to happen was. Most HW basd firewalls will give you a log of URLs, but even that can be like finding a needle in a haystack.

Re:sandbox it maybe? (1)

roman_mir (125474) | more than 4 years ago | (#32711530)

write log files to a dedicated partition maybe?

Re:sandbox it maybe? (1)

Skal Tura (595728) | more than 4 years ago | (#32714158)

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 (3, Insightful)

Anonymous Coward | more than 4 years ago | (#32709880)

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 (4, Funny)

AnonymousClown (1788472) | more than 4 years ago | (#32709916)

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 (4, Funny)

PrecambrianRabbit (1834412) | more than 4 years ago | (#32709944)

$ grep vulnerability *.c | wc -l

Everything seems fine here to me...

Re:license has nothing to do with security (1, Informative)

Anonymous Coward | more than 4 years ago | (#32710252)

you're looking for
$ grep -c vulnerability *.c

Re:license has nothing to do with security (0)

Anonymous Coward | more than 4 years ago | (#32710494)

That's in the Advanced Security class.

Security through obscurity (5, Informative)

PrecambrianRabbit (1834412) | more than 4 years ago | (#32709932)

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.

Re:Security through obscurity (0, Redundant)

Anne Thwacks (531696) | more than 4 years ago | (#32710002)

Mod parent +n, no shit!

Re:Security through obscurity (0)

Anonymous Coward | more than 4 years ago | (#32715720)

Indeed, and this isn't about buffer overflows in real applications such as httpd.

Web "applications" are the Special Olympics of hacking.

These are all scripts. Vulnerabilities in such toy languages are not only far easier to discover, they are also many orders of magnitude easier to exploit, regardless of exposure to the individual script.

Using native apps in a modern OS the attacker will have serious problems to inject any command any small side effect is a treasure.

Careless web scripts will happily run any code or command you introduce trough a vulnerability, and have access to absolutely all the files the attacker is interested in.

If you want to rely in security through obscurity be sure to develop your own scripting language and database query language. Don't forget basing them off an esoteric language that can't be figured even after a bug in your scripts dumps most of the source.

Of course, then you might have to pay your developers more than one rupy a month.

Re:Security through obscurity (1)

Quirkz (1206400) | more than 4 years ago | (#32716814)

Yes, absolutely true. Though if you're lucky, especially in a game scenario, that "experienced attacker" might also be a friendly, curious player who will provide great services by finding the bugs and alerting you about them.

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 the system and take any advantage they can. Hopefully there are enough friendlies catching the worst bugs early on that they edge out the malicious attackers.

Disaster Planning (5, Interesting)

Anonymous Coward | more than 4 years ago | (#32709946)

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? (4, Insightful)

noidentity (188756) | more than 4 years ago | (#32709952)

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.

Re:Securing server, preventing cheating, what? (1)

fishexe (168879) | more than 4 years ago | (#32711710)

Each of these has different costs when breached.

Not to mention, different countermeasures.

just assume you will fail (3, Interesting)

Surt (22457) | more than 4 years ago | (#32709976)

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 (2, Informative)

ashridah (72567) | more than 4 years ago | (#32710590)

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

Dashiva Dan (1786136) | more than 4 years ago | (#32721932)

I have no points to mod you up, but I was planning to make a similar post if noone else had (till I read yours just now).
I used to run a MUD [] . 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: Javascript, Apache, MySQL, XSLT, etc.

While I never had any serious hacking of the game, There were bug exploit type hacking (item duping, etc) that happened from time to time.
Anyone who tells you you can make your application secure is a liar :) Sure, you can close up the most obvious holes, but I think we all know it is impossible to make a system completly secure. Look at Windows, Mac OSX, games like WoW, etc.
While it's right to be considering the issues and doing your level best to prevent security holes, and a lot of the advice here is decent, and some really good, your primary defense is backups. Back up everything, particularly the data the game uses. When things go wrong (and unless you're amazingly lucky, they will), you can do a restore/rollback/whatever, and while that will upset a few users, they won't quit, and they won't lose respect for the game.
Log all you can, but unless there is money involved, don't spend more money to achieve security for logfiles, etc. Just do your best on your budget, and go with that.
Until you have an average of 500+ players on at any given time, and over 100,000 active users, ironclad security is not expected. (Yes, I pulled those figures out of a hat, but you know what they say about made up statistics)

Any case. Back the data up, and everything else is secondary.

Two sides of the coin... (1)

Aphrika (756248) | more than 4 years ago | (#32709986)

For every person out there who finds a hole in your code and tries to exploit it, there will be someone who will help and patch any holes - if they exist.

mod security (2, Informative)

voot (609611) | more than 4 years ago | (#32710006)

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.

A few things (5, Informative)

raddan (519638) | more than 4 years ago | (#32710016)

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

Please, do allow multiple logins. (0)

Anonymous Coward | more than 4 years ago | (#32714588)

Please, do allow multiple logins. Did you see any big website forbidding it? Gmail allows it, slashdot too, wikipedia too, even ssh does.

There is a website that I need to use. The problem arise when it just tells you "you are already logged in. Try again in 15 minutes". There are times when the site is so slow (imagine hundreds of people trying to access this website at the same time, and its not built using scaleable tools), so you can wait hours until you can actually log in.

Speaking from 10 years ago (5, Interesting)

ducomputergeek (595742) | more than 4 years ago | (#32710060)

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.

Frameworks and Risk Planning (0)

Anonymous Coward | more than 4 years ago | (#32710076)

Some say using a framework can help prevent known vulnerabilities in your code. That way you don't worry about security as much. On the other hand you may be like me and not like frameworks as much. I use a set of classes and validation techniques I have learned over the years. You should do risk management when operating the game. Even the top game developers like Blizzard deal with security holes.

Start with Linux Intrusion Detection System (LIDS) (3, Informative)

PatPending (953482) | more than 4 years ago | (#32710080)

For a start, consider using LIDS []

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

Re:Start with Linux Intrusion Detection System (LI (0)

Anonymous Coward | more than 4 years ago | (#32716016)

Cool! Is that included by default? Oh, I checked Wikipedia, nevermind.

Watching it closely it seems overly complex. And a patch. I am so going to waste my time building my own LFS...

Wake me up when Linux is secure by default.

Learn to fucking code (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32710122)

Hiding the source just means people who are smarter than you can't help you.

It's all in the code. (0)

Anonymous Coward | more than 4 years ago | (#32710130)

It almost sounds like you're looking for some sort of magic IDS or IPS. They don't work like that. Your security is all what you do. Security should a factor for every piece of code written, before implementing some function or even line of code you should think about how secure it is and in what ways it could possibly be misused.

With secured code you can think about other things. Keep your servers patched. Use an enterprise type distribution. Limit installed software and of course disable/remove unnecessary services. Limit remote access to only the hosts that you know will need it.

I've been doing managed services for quite some time. Our customers get root access and can do what they want. The majority of compromises are due to bad code. Weak passwords come in second. Compromises dues to OS or standard services are practically nonexistent.

Game or not, web app security is web app security (4, Insightful)

twistah (194990) | more than 4 years ago | (#32710312)

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:Game or not, web app security is web app securi (2, Informative)

Daem0nX (718135) | more than 4 years ago | (#32711564)

For encryption check out []
"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:Game or not, web app security is web app securi (0)

Anonymous Coward | more than 4 years ago | (#32713582)

My job is the same as the person asking the question, although we don't release to open source.

The above, I would say, barring a few minor points is correct.

I'll add a little bit. I'm assuming that it says to use magic_quotes_gpc. Don't.

It may seem labour intensive, but you're better off escaping each string as required with the escape routine for where you're sending it.

magic_quotes_gpc is dangerous. It's generic, so not really the best thing in many specific cases (all cases are specific to something) and it's not always clear where you need to use it. It doesn't apply in many places. I've seen many programmers caught out by this. For example, taking some data from user input from where it is escaped (ie _REQUEST) and storing it somewhere (database, local file, anywhere) then retrieving it later from that source, finally putting it back, assuming that it was escaped in the same way it was when retrieved from use input (actually this can happen without magic_quotes_gpc but not as easily as with proper escaping you're actually always keeping in mind what needs to be escaped rather than believing in magic). It might seem convenient, but in the long run, well there is no long run, you can't win a marathon by sprinting all the way. It will also be a nightmare to get rid of it later on as it isn't explicit in the code as to where it is being used. Furthermore, it's useless for stuff like query('SELECT * FROM table WHERE id='.$_GET['id']); Ensure that you always use the optimal escaping function for whatever system your data is from and for. Ensure you are aware of all the relevant functions such as shell escaping functions, database specific escaping functions/prepared statements, html escaping functions, javascript escaping functions (json will usually do), url escaping functions, etc. If a programmer can't handle that, they're in the wrong career and need to be doing something simpler (e.g. basic html, helpdesk, data input as long as it doesn't need thought and is limited to manual copying+pasting from paper to database as c&p is about as much as these people are good for). Besides that, you'll have to use these escape functions explicitly anyway when getting data from pretty much anywhere other than the user so there's no point confusing everyone and mixing it up. There is no real magic. Also, actually consider checking the user input it what is is supposed to be. If you do that, you often won't even need to escape. You could use magic_quotes_runtime to try to escape stuff from other sources, but besides having to know what sources it affects (many wont be), it'll also drive you up the bloody wall when you need to pass it to something that doesn't need it to be escaped or escaped differently, having to constantly unescape, annoying enough with only gpc.


I could give out a hundred [+- some] examples/tips and justifications (angry justifications as I've had to fix a lot of bs code, I really hate other PHP "programmers"). However, that's beside the point. I recommend, that if you don't know this stuff, find people who do and have one or more of them review your code before release. Ideally, a benign hacker (ie white hat or whatever they call it). Your security concern is that someone will read the code to find bugs, that wouldn't be found so easily without such access. So give it out to someone (trustworthy) that will do the same, in a benign manner before releasing it to the public. Release it fully to the public once no one that you've given the challenge to can find a way to hack it within a reasonable amount of time. After such a process, it could still have security issues but they would be allot harder to find.

Additionally, turn on warnings and notices (in the log). I've found that by doing this and fixing everyone, many otherwise uncaught bugs get fixed and the resulting code is more exact. Being exact is important, the more scope you give for a script to accept anything other thant what it's supposed to accept, the more scope for abuse. Many warnings and notices will be trivial. However in my experience, I've found this usually detects enough bugs to be useful, unless that code is totally fubared and spits out so many warnings/notices that the server dies as log access drowns out HDD IO. Not all, but enough of such bugs are security related. If you do this before releasing, it should help clean out allot of easily found nastiness. Why are notices important as well as warnings? For example, undefined defines resolving to strings of themselves amongst other things. If someone says notices aren't important punch them in the face, they're too stupid to be convinced with rational. You may also want to turn on strict from time to time.

In my opinion, sanitising you code using methods like the two above is most important thing to do before release along with ensuring disaster recovery is in place. Particularly getting someone who already knows the huge array of security issues to review the code for first would probably be more productive than looking at random and non-holistic lists of security pointers.

Integrate bug reporting into it, so that if anyone hosts it when it is released, it's easy for them to submit bugs. After release the discovery of security issues should decline overall, barring new feature inclusion. Once it has been open for a while, in theory, security should return to normal.

Re:Game or not, web app security is web app securi (1)

twistah (194990) | more than 4 years ago | (#32713672)

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:Game or not, web app security is web app securi (1)

chris.armstrong (1806988) | more than 4 years ago | (#32713974)

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 code, provide you with a source code management server and an issue tracker and mailing list.

The other commenters have also given good advice on securing your server and limiting any damage that might arise from an attack. I would only add that you might wish to get someone to perform a code review on vulnerable modules before you release it, in order to minimise making any exploitable bugs apparent.

Sounds Interesting Where's the Source Posted? (1)

monk (1958) | more than 4 years ago | (#32710334)

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 Progress" page.
When you're ready to come back up you can restore from a previous snapshot apply the patches that fix the hole and move on with life.

Obviously game state makes this harder, so alot depends on what you can do to make the app support this.

Anyway, your project sounds cool. I'd like to see it.

Don't use PHP (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#32710432)

95% of PHP coders are interested in solving a problem, not security. This means that the PHP community is less likely to find and complain about insecure implementation from the core PHP team.

Obviously, there are exceptions to this statement, just like fantastic, secure code can be written in VB or Python or Ruby. It just happens that isn't the usual outcome, but it could happen. It could, seriously.

This is my approach (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32710644)

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

Project Name / Location? (1)

Xaroth (67516) | more than 4 years ago | (#32710780)

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? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32711094)

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.

Why, oh WHY?! (0)

Anonymous Coward | more than 4 years ago | (#32711846)

It's fortunate you're using PHP... with all the segfaults I see in php, combined with the way php cripples your efforts, your game server probably won't be up long enough for anyone to hack. :-)

Anyway, check into FastCGI, I've never used it with PHP, but it supposedly works with php too.

The upshot being, you can theoretically, run the FastCGI process in a chrooted environment, separate from the web server. (in fact, using FastCGI, you could run your application on a completely different machine from the web server (or a BSD jail, etc..)

This provides some degree of security, as people who might break in will not have access to other web stuff. (good luck getting PHP and it's million mile list of libraries in a chrooted environment..) In the case of real languages, FastCGI is really, really fast too. (if you plan for it) because you can pre-allocate data structures and hang on to objects for multiple requests.

OWASP Application Security Verification Standard (1)

ajv (4061) | more than 4 years ago | (#32712814)

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. []

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, validating and ensuring that it meets business logic requirements (such as not being able to pass through walls, or avoiding object collision algorithms, asset or stat manipulation, or score manipulation. The client is completely untrustworthy, and you should be writing your code with that in mind 100% of the time.

I lean towards publishing the code. The only secrets you really need to protect are master authentication tokens in (say) config.php and authorization tokens in flight. So don't publish the master config.php secrets in SVN or similar, but everything else should be completely open.

Web game security 101 (1)

eison (56778) | more than 4 years ago | (#32713184)

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 disguised in various ways. A whitelist filter of allowed html is safer than a blacklist, but you still have to manage to consistenly scrub input.
  - The fact that passwords are essentially inadequate, but it's hard and/or expensive to come up with anything better. So force decent passwords, remind your users not to give them to their friends, and anticipate there will be some level of "my angry ex boyfriend deleted all my stuff" support requests so history logs of important actions and the ability to roll stuff back will be useful.
  - There *are* more types of things that can be done ("clickjacking", "sidejacking", dns poisoning) but I think the above cover most problems you really need to plan on.

2) Next, you have to protect your game.
  - Malicious users. It's particularly easy to be a malicious user with HTML - the web app provides a nice form variable "itemid=12", I can change it to "itemid=1", poof I have your super wizard staff. You can't trust your users, ever, so write your app so that impossible things aren't permitted.
  - Bots - if there is any instance where user activity is rewarded, somebody will find a way to automate it. It's a problem from a purely technical server load perspective, and it's also a problem from an upsetting good users viewpoint. Good luck here.


Anonymous Coward | more than 4 years ago | (#32713584)

Check out the OWASP [] site for a good introduction to web security topics/techniques. There is plenty of information across the site to give you a start on what you should be doing.

You'll want to look at implementing things like:

  • CSRF tokens (including use of a strong PRNG for generating nonces where you're *not* leaking the internal state of the PRNG at any point of time - example [] )
  • X-Frame-Options (prevents clickjacking)
  • X-Content-Security-Policy (prevents clickjacking and XSS bugs)
  • HttpOnly (cookie flag for extra XSS protection)
  • Use of common code in your game for creating sanitised SQL queries, outputting sanitised strings, etc.

OWASP and more (1)

Cato (8296) | more than 4 years ago | (#32713688)

Here are a few pointers, mostly around PHP web app security:

- [] - the Open Web Application Security Project has a comprehensive list of things to cover - see their [] (top 5 PHP issues) in particular

- [] Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping

- [] - ensure include files can't be reached directly from HTTP.

- [] - use [] -PHP Filter features]] (only in PHP 5.2.0 onwards)

- [] - monitors your site for free to detect compromises that affect readable pages

Final point: don't "filter out" dangerous characters, this is never ending and can never be done - instead, for any given parameter or input field, define the valid characters (e.g. alphanumeric, date, etc) and specifically allow ONLY those characters. This 'filtering in' approach is far safer.

The Open Source Perspective (1)

ags (145597) | more than 4 years ago | (#32713908)

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 email about a security vulnerability. And yes, that feels bad.

Do your very best; don't worry, and enjoy being part of the open source community.


Minimal Server ... (1)

ScaledLizard (1430209) | more than 4 years ago | (#32714384)

Does your game really require a server? Servers increase cost for open source projects, so I would run as much code as possible on the clients. Granted that you need the server to set up the games, but all actions could be refereed indepently by several clients. If they don't agree, this may mean that someone is using a hacked client, and a warning should be displayed. The more players participate in such a peer-to-peer game, the more clients would have to be hacked in order cheat, but of course a single vulnerability in your system may still be fatal for security.

PoissonPilote contact me (1)

FormOfActionBanana (966779) | more than 4 years ago | (#32722830)

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.


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?