I am in the process of coding an online game in php. I have a lot of experience in this field and have seen many competitor sites lose ranking and popularity due to hackings, and cheating via exploits. I of course want my site to be on top, and I want it to be completely secure. Obviously my users are not going to be happy if their passwords are hacked etc. The site is running on mysql. I am trying to secure the site from javascript inputs, generally malicious inputs relating to sl injection and xss etc. I have designed a lot of the site and I am struggling to come up with a way of securing the site without edditing each and every query. I have now realosed it is probably a neccesity. I am willing to pay (although only around $10), If you could make me a class/ function which I can use to completely secure a site containing a lot of user inputting etc. I know you are extremely experienced, and thus your help would be greatly appreciated. Thanks Tom
There is a good bit of input verification code available for the Smarty template system. It looks well coded and is easy to understand, making it easy to adapt to other situations. It is available here: SmartyValidate You have no choice but to make sure every bit of user input is what you expect and to make sure it is the correct data type before doing anything with it. If you expect numbers, make sure the entry only has numbers. If you expect letters of the alphabet, make sure it does not contain other entities. In terms of your users passwords being hacked -- that is their responsibility. You can try to enforce rules about the complexity of the password. That makes it harder for them to be hacked. But, not impossible.
Well Ive seen sites hit by sql injection, xss etc whereby putting malicious values into forms such as OR '1'='1' as a username value.. I have heard all sorts of stuff about adding and removing slashes as well as magic quotes which I have no clue about.. would you care to explain? Will validating all form inputs remove the need for the above? Also if I am to validate all form inputs I'd rather code my own class/functions what should be validated/romoved ftom form inputs? Thanks
I really don't know about xss. But, for the other half of your question... SQL injection can be a nasty, subtle thing. Keep in mind that a lot of PHP has been written which ignores it. The basic idea is that, if you aren't careful, a hacker can submit requests which let him run arbitrary SQL on your system. So, the attitude to have is "Never trust user-supplied input." It sounds like you have the basic idea: validate and verify everything that comes in with the request. It's just that that's easier said than done. I'm away from my "real computer" right now, so I haven't had a chance to try out any of these examples. Plus, it's been a while since I did any PHP, and I really don't have time to go dig through their documentation [which is something you should definitely do] just now. But this should give you an idea. Here's an example of Really Bad Code: $sql="insert '{$_POST['username']}', '{$_POST['$password']}' into usertable"; $db.execute($sql); Code (markup): This is bad because a hacker could set, for example, the username to something that screws up the sql--maybe inserts a "select * from usertable" into the middle of the query, which returns him the list of all the user names and passwords. (One way to do this would be to add quotes into the middle of the user name to cause sql errors, examine the error messages, and go from there). The add slashes and magic quotes functions (as I recall) are designed to help prevent this from happening. Basically, they "escape" dangerous characters so they play nicely with SQL. So they're pretty much the bare-bones bottom-line level of security. Next level: if your database supports stored procedures with parameters, use them. It's [generally and probably] faster, and now things are almost guaranteed to be safe. Even further: If you can set up access rights on the queries, do it. The bigger the system, the more paranoid you have to be. Maybe you'll have one database user with access rights to create user accounts, another which can query for a particular character's [or whatever] state, another that can update the state of the game world, etc. Or maybe that's completely overkill for now. Doing this means that, if one aspect of the site gets compromised (and, eventually, it almost certainly will), the rest doesn't fall down like dominoes. Finally, Clancey's idea about verifying the types of various data can also be a good one. You just have to decide whether it's worth taking the time to write the code to parse the strings in the request fields to prove they're valid. Personally, in most cases, I just assume those types are okay, and handle errors as they happen. Which reminds me. Always check for errors! And be careful about what gets shown to the users. Detailed error messages help hackers. In general, you want to log all the details and display some generic "Oops, why don't we try that again?" message to your users. Anyway, that's sort of the basic idea. Personally, there's no way I'd write a $10 script for someone else to try to secure their site. And I wouldn't trust one of my sites with a $10 script that someone else wrote.
The answer is simple, The implementation is not always. You remove anything which does not belong. You need to know what kind of results you expect and reject the rest. Your computer is not smart enough to know the difference between good and bad input. You need to define what is good and reject the rest. It obvious that you need to spend some time at sites where they discuss various security problems and ways to combat them. I would do searches on the problems you identify and carefully read the siggested fixes. The above library I mentioned will help a lot.
As an update to this thread. Clowes and I continued the discussion offline. That resulted in am open project called the STAT Secure Web Project, with the first bit of code being a script which automagically secures form input. I do not know if all possibilities have been considered. The script is fairly short and is simply included in a settings.php or init.php type file -- something called by every script which might process form data or cookies. You can download it -- it is open sourced -- and test it out on some project you have underway. The link is STAT Secure Web Project Clowes problem is that the project was fairly developed and enclosing every access to form variables in some kind of cleansing formula was a huge undertaking. This solution takes a second aand , in my tests, seems to work.
Clancey is an incredible programmer, and the STATsecurity project will go on to be a great, and successful one. Clancey has been a pleasure to work with and has helped me a lot. Thanks
Whoa . . . thank you I am glad our collaboration worked out for you. Hopefully the result will help others.