An introduction to security
by
Published on 04-05-2011 01:47 PM
When developing games, it is very common to have a lot of youngsters with a little knowledge "probing" your system looking for the simple exploits. Now personally I run "sentinel" loggers which permit the little blighters to try anything, although my systems are secured against 99.99% of attacks. On a daily basis, I check the logs looking for patterns that may indicate a new trend, and require some extra protection. Any attackers are often (but not always) added to my BLIP (Blocked IP lists).
So just how do we prevent intrusions?
Well the best and most secure web site is:
Although some people will say that even that can be circumvented by social engineering.
Security actually takes a large number of forms so I'll start with the simple ones and work upwards. If you don't follow what I'm trying to demonstrate - then back to school you go. Read the manuals thoroughly until you do.
As a quick side note - for anyone who is curious as to my abilities and knowledge, I've worked for the military, government, police and security services and hold regular discussions with my peers all of whom run large (> 100 public facing machines) networks.
Obtaining your source files
I've seen a lot of illegal copies of software out there - and often it has been badly patched. If you want to run a game, great, but don't steal the software - you will hopefully make some money from it, the original sources are not expensive, so buy a copy.
I have to come clean here and admit to having an illegal copy of some software, however I run it on my local in-house machines for my personal enjoyment only (and gaming is no fun on your own). I would never make it publically facing nor would I attempt to sell it or gain any finances from it by selling extensions for it etc.
One particular case I looked at recently, a game owner "obtained" a copy of xxx code, installed it and called for my help when his entire site was badly hacked. A quick look, and I realized that several files had intentional patches written by somebody else that permitted these exploits. Since the source was illegal and the poor owner couldn't understand what he'd done wrong, I was unable to help.
A little point here also - don't steal modifications - I've had a couple that suddenly appeared on other sites. Now, trust me folks, I recognize my style of programming. If I see my stuff out there that has not been released as open-source, better find yourself a good lawyer.
Installing your files
This is a little harder to explain, but there are certain tricks that can be done to help secure a site.
If you can, find a host that allows you setup out-of-root folders:
With this system, it becomes almost impossible for users to access information outside of the web root.
Remember however, you will need FTP access - If you allow other developers access to the FTP account, either try and set up limited accounts (i.e. access to only the htdocs folder) or make sure you trust these people 100%.
The older developers amongst us are relativly good at trust - We have been around long enough to know what the possible problems with trusting users is and when we can allow them access to restricted areas. Unfortunately, a lot of younger people think they can make a fast back by nicking the odd bit here and there. Don't - it's not worth it.
A note on passwords here... You will of course have CPanel (or it's equivalent) passwords, passwords for your database, passwords for the FTP server etc. If you can, change these regularly and NEVER give out the database password to anyone. If your data is corrupted, stolen, overwritten etc - You lose everything. Passwords should be very heavy duty for these primary areas - I use 18+ alpha-numeric-punctuation here for example: "DeveloPING_85_bunnieS" is fairly strong whilst "football" is just ridiculous. Don't use the same ones anywhere else, don't write them down, don't store them in text files in your web root (I've seen it done), don't store them on your own personal computer - remember them.
Testing your site
Disable the registrations system. You can normally create users on the fly in the staff/admin pages. This will allow to run with 5 or 6 trusted people who will help you find those bugs and do some basic testing. If your site relies on crons to update various parameters, try scaling these so the game runes effectively a lot faster. This way you can go through each area of the game properly without resorting to editing your stats by hand and check everything out within a couple of weeks rather than possible a few years. (The courses I have for one game would take just under 5 years real time to complete - took me a few days by running everthing in a high speed).
Finding bugs
Turn on all warnings and errors: error_reporting(E_ALL); and fix EVERY warning. Yes, I know it's time consuming, but trust me - It's worth it. I will be releasing some code to help you here soon, but ideally you should be able to track down and fix all those pesky warnings and errors.
Range checking
Okay, hands up... How many of you have seen prices for items in various games at -2,147,483,648 or 2,147,483,647? Range check every number that a user can type in. I always restrict the values that users can type in. Make sure you check that your range checking works properly. PHP has issues with signed and unsigned numbers at 32-bits and 64-bit is not real help. In fact at 64-bit PHP loses accuracy rather quickly as it converts what would appear to be ints into reals.
Cleaning GET and POST data
This is a massive stumbling block for a lot of people but is critical.
You MUST check everything - If you expect a number, make sure it is a number. If you expect a string, make sure you strip slashes, remove quotation marks etc.
See stripslashes(), preg_match(), ctype_xxx(), htmlentities() etc.
Pushing data into the database
Oh lordy - now we have fun...
Too many times, I blow sites up for using:
No, No, and thrice NO!
Yes, it's longer to write -- It looks possible a little more complex as I have back-quoted field and table names, but trust me - if you don't - your site WILL get damaged.
I'll go into more detail on this one in a future topic...
Transactions
This is probably for the more experienced developers, but it is something worth considering. Transactions are a method of grouping together database queries (during insert/delete/update) and having the facility to "rollback" if something fails.
Why? Well one particular very-well known I site I play on, I accidently double-clicked a particular link which removed a lot of game cash from my account and updated several tables. Unfortunately, because transactions were not in place, the system took twice the amount from me, so I was left in the red for a very long time. I contacted the devlopers and they could not find the problem - pfft, amatuers!
Unfortunately, transactions can be difficult to understand, but a thorough read of the MySQL documentation and some time experimenting on a local machine can pay off here.
Staffing
This can be problematic, I've seen too many games with terrible staff. Get people you know are 100% sound. Create twin accounts for them - a normal account and a staff account. Block any attempts to change their normal account stats, items etc.
You may want to think about a legal agreement preventing them from using anything the see in the staff/admin pages elsewhere. It's not much, but I now require all staff to sign written documents which are basically a form of protection.
A little note here - My in-game mail systems are modified from the norm - I never delete any mails from the servers (okay, I've several Tb of storage per machine), which means I have a full audit trail of any dodgy dealings. I also prevent staff from looking at ANY mails (a simple privacy issue here) unless there has been a reported incident.
--
There's probably a lot more I could go into - so I'll probably add some more notes in the future, but hopefully, these few random thoughts will help give you a better idea of how to protect yourself and your users and give everyone a more enjoyable experience.
Specific inquiries re. this topic should be addressed in the forums for ALL to see, not via PM. I release my source, my thoughts etc as public domain in an attempt to help others - you should help others by being open about what you do. Remember, the game engine you (hopefully) bought, is just that - an engine - not a game. A game has content, looks good, works and is secure. The content is what makes people want to play - not the engine.
vBulletin Message