Hmm this section needs something

[Decepti0n]

Some fun!

1. Use ctype_digit() to validate your input when you need to make sure they only enter numbers

2. Always create custom functions for things that are repeated often, such as displaying or calculating things

3. Always check any input in the database first, NEVER insert any unchecked data

4. NEVER allow users to externally host their pictures. Even checking the extension of the file does nothing, use file_get_contents and preg_match() to ensure that the picture isn't disguised as a PHP file

5. NEVER allow users to use html anywhere. There's about ten different ways to insert javascript via html, which isn't too fun if they know what they're doing.

6. Decide whether to whitelist of blacklist: a whitelist checks any input, and if it isn't in a pre-defined array (or however you decided to check it), it refuses. A blacklist simple refuses certain pre-defined words, and accepts all others.

7. NEVER totally trust any form data, even radio fields, checkboxes, or even hidden fields. They can all be tampered with

8. Try to stay away from using the md5 hash. Its huge use has lead to massive databases of all possible combinations. Develop your own function, accepts a string, uses various string functions (substr, str_repeat, str_shuffle) and other algorithms (sha1) or multiple.

9. NEVER use crons that run every single minute. Nearly every function that uses a cron can be replaced entirely by utilizing and calculating different timestamps. I completely removed the energy refill, stamina refill, jail/hosp times, days old etc crons from my game by converting.

10. Comment your code! If you can't go back in 2 weeks and instantly know what piece of code does what, you've failed. Comments are all to you, so don't be against writing notes, having 14-line comment blocks or commenting even the smallest things

[mdshare]

Re: Hmm this section needs something

looked at by a smf developer (showed him your stuff ;) )

 

6. Decide whether to whitelist of blacklist: a whitelist checks any input, and if it isn't in a pre-defined array (or however you decided to check it), it refuses. A blacklist simple refuses certain pre-defined words, and accepts all others.

In general, whitelisting works best for security purposes as it only allows things you have defined. If you are permissive (blacklist), an attacker can try a vector you have not anticipated and get around things. Remember the principle of least privilege.

 

8. Try to stay away from using the md5 hash. Its huge use has lead to massive databases of all possible combinations. Develop your own function, accepts a string, uses various string functions (substr, str_repeat, str_shuffle) and other algorithms (sha1) or multiple.

You don't need to abandon MD5, but you shouldn't be using it for security purposes. Dictionaries of common (or even all possible) hashes is nothing new. The best (and a rather old) solution is to salt the passcode before hashing it. Doing this stops dictionary attacks as even the proper reverse text will be invalid as you'd need to account for the salt value. That leaves the cracker to brute force, which will take significantly longer. MD5 is fairly quick to brute due to flaws in how it was designed, so I wouldn't use that for passwords anymore. Likewise, SHA1 has been "broken" and looks like it might start getting easier to brute as well, so look at using a more secure hash method when security is vital.

 

9. NEVER use crons that run every single minute. Nearly every function that uses a cron can be replaced entirely by utilizing and calculating different timestamps. I completely removed the energy refill, stamina refill, jail/hosp times, days old etc crons from my game by converting.

Sometimes you need a process to run once a minute, sometimes you just can't get past it. However, if you only need a job to run at a certain time, schedule it just for that time, it keeps the load down. If you need it to run periodically, always ask yourself what is the longest period it can go without running.

 

10. Comment your code! If you can't go back in 2 weeks and instantly know what piece of code does what, you've failed. Comments are all to you, so don't be against writing notes, having 14-line comment blocks or commenting even the smallest things

Expanding a bit, get a code style and stick to it. Being consistent in how you write your code will help when you need to look it over in the future.

For functions, documenting the purpose, input, and output at the top of the function is a smart thing. If you did something tricky or something unclear, put a comment by it so you know why it was done.

Keeping your code straightforward is the best documentation you can do. You don't need huge comments unless you are either doing formal code documentation or the code is so complex, you can't understand it in by scanning it over, and comments that big are often more of a hindrance than a help.

[Decepti0n]

Re: Hmm this section needs something

Yeah, my comments are usually huge in production, when i upload though, I summarize it :P, and I use salt plus a custom hashing function usually :P

Geez dont quote me on that I wrote it like as I went when I was bored one night :P

[UCC]

Re: Hmm this section needs something

I still have a hard time understanding this cron elimination business. I think I understand the concept but it bugs me that it only makes changes to active users.

If Player 5 is attacked and beaten by Player 6while offline, they end up in the hospital. I understand that when timestamps are used, he can login and with a little math, it's clear he's now out of the hospital. Ok, so he's happy. But lets say Player 4 wants to to beat up Player 5 too. So they want player 5 out of the hospital even though Player 5 is offline. So what triggers Player 5 getting out of the hospital? I guess you could do the calculation when someone ran viewuser.php on Player 5, or for every player every time someone views the Hospital. But then you start to get to a point where I feel you're almost doing more queries than a cron would have in the first place.

Oh yea, and about passing stuff through with Forms. That's a good one. Some of my early mods were hacked that way. Now I know better. :) Always veryify the data.

[Decepti0n]

Re: Hmm this section needs something

Mine updates when they visit the profiles page, but I might change it, thats the only way I have it now. Instead of updating almost the entire table of players, it just gets the one that a) is being viewed by a profile and b) actually has less health/is in hosp.

So far I haven't noticed anything, but its relatively small-scale, so we'll have to see how it works out in a bigger game.

[Guest Null]

.

Just trying to get this thread back up as it addresses vital things. Also, if anyone reads this, Is it possible , when you have a whitelist, when something isnt in the white list array, could u use something along the lines off.. if(!in_array(stuff here)){ echo 'Those characters are not allowed'; $char={$_POST['var']}

function_name("Suspected Injection Attempt: {$char}"); where function name would be a function similar to stafflog_add, but is mainly to add to a list on a different page.