Tips on Web Security

[JPC-Masood]

Here are some tips to keep your site secure. This was primarly written in response to a hacked site:

1. First thing you need to do is check all vendor/developer sites for ALL web scripts/applications used in your account for any update including any mod you may be using in any web application. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them upto date. Check the database on www.secunia.com for any known exploits released in public.

2. Once you have verified that 100% of scripts are latest stable, you will need to go through all files of your account and make sure none is uploaded by hackers before you audited or left by you from an old install of an application. There may be files in folders you would never imagine. You can use ftp or cpanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup]

3. Make sure all passwords are mix of alpha-numeric and not a dictionary word. Just because you thought of a difficult word from dictionary does not make you safe.

4. The MySQL database access to all web application should be using separate db users. Do not ever use your main account user/pass for it. Your main user/pass should never be stored in any file in your account.

5. In your control panel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stats. If you have already been hacked, its too late now but you can archive the logs for future attacks.

6. If you have customized a web application with a mod, make sure it is also latest stable. Many popular web application may be stable but one of the addon mods are exploitable, which may not be maintained any more.

7. If you have written some code yourself, make sure all input variables are sanitised (checked for valid data before using it). Otherwise a single line of bad code can give access to your entire account. The usual blunder is to include a file based on user input. Again, make sure all input to a script is checked for valid data. All exploits are based on input data. If your site does not take any input, you are 100% safe from web exploits, i.e. if you run 100% static html site with no script whatsoever anywhere in your account.

8. For php, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications.

9. If you have some mail script, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. Here is a code snippet that you use against all input variables from the form:

//should not allow empty breaks in your mail or subject

//check name, email, and subject
if ( ereg( "[\r\n]", $name ) || ereg( "[\r\n]", $email ) || ereg( "[\r\n]", $subject) ) {
   header( "Location: $errorurl" );
   exit ;
}


//or put everything you want to check into an array and check it all
$checkme[] = $name;
$checkme[] = $email;
$checkme[] = $subject;

foreach($checkme as $check) {
   if ( ereg( "[\r\n]", $check) ) {
      header( "Location: $errorurl" );
      exit ;
   }
} 

should probably clean the mail before using it:

$mail = str_ireplace(array( "\r", "\n", "%0a", "%0d", "Content-Type:", "bcc:","to:","cc:" ), "", $email);

$subject = str_ireplace(array( "\r", "\n", "%0a", "%0d", "Content-Type:", "bcc:","to:","cc:" ), "", $subject); 

in fact no real reason to even allow html tags in your subject, and so feel free to just use:

$subject = strip_tags($_POST['subject']); 

and just good practice to make sure the end result is formatted: correctly

if (eregi ("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)+$",$email)) {
//good
} else {
//bad
} 

10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.

11. If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before.

12. For added security, change the permissions of your configuration files (having database credentials etc.) to 660. You can do that via ftp or file manager.

13. For added security, if you can block access to certain administrative sections of your site, do that by giving access to only authorized IP addresses and blocking access for everyone else, Or password protect it.

14. If there is any file upload facility in your account, make sure that only authorized members can use it.

Also the uploaded file should not be accessible via web URL directly (i.e. stored outside of public_html) unless

a) it is only uploaded by a site admin (responsible person)
b) checked and validated to be not exploitable

15. If there is any URL forwarding or Webmail facility for your site membership, make sure it is not given to all without proper authorization or it could be used for spamming.

16. If you're just testing / trying something, which only you need and you know you won't actively keep up to date, just lock it behind a password right away.

17. Since JaguarPC shared/sdx/resellers servers come with phpsuexec, you do not need any file or folder with world write permissions. The normal folder permissions should not exceed 755. And php/html files can be 644 (or lower through ssh). CGI/perl scripts can be 755.

18. Anyone who writes web application code, should be familiar with security. I found this book in my local Library particularly on php: http://www.oreilly.com/catalog/phpsec/ I recommend it to all. It covers all apects of vulnerabilities found today in web applications. Found this site as well from the book: http://phpsec.org

Wim's recommended reading: php|architect's Guide to PHP Security
publisher's store -- Amazon -- Author's blog

If you have more tips, please post.

[Vin DSL]

2. Once you have verified that 100% of scripts are latest stable, you will need to go through all files of your account and make sure none is uploaded by hackers before you audited or left by you from an old install of an application. There may be files in folders you would never imagine. You can use ftp or cpanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup]...

Funny you should mention that!

My e107 (beta) site was defaced in June. I checked things out, and have been monitoring it since. It was okay, so I just left it up, defacement and all. Kinda funny, actually...

Anyway, last night I got bored and decided to fix/update e107.

I was running 0.6172 -- the latest stable update is 0.7.7 (which has been patched already)

I'm short on time right now... but if anyone is running e107, let my experience serve as a negative example to you. Don't do what I did!

Upgrade to 0.7.7 ASAP, and apply the security patch to the Chatbox! If you'll pardon the pun, the hackers have e107's number!

BBL

[Gwaihir]

16. If you're just testing / trying something, like that e107 thingy of Vin, which only you need and you know you won't actively keep up to date, just lock it behind a password right away. Makes it darn hard for anyone to exploit it.

Fantastico makes it really simple to install something to have a look at it and fool around with it for a bit.. and then forget about it. However, I install such to a folder on a password protected subdomain to keep it nicely worry free.

[JPC-Masood]

That is a good tip. I have merged it in the original post and added one more thanks to Veena for reminding me

[JPC-Masood]

One personal recommendation added for coders.

[Gwaihir]

18. Personally like this one better :

php|architect's Guide to PHP Security
publisher's store -- Amazon -- Author's blog

[JPC-Masood]

Thanks, post updated.

[Dab]

The link ( http://jaguarpc.com/forums/showthread.php?t=13182) in point 9 doesn't work.

[Vin DSL]

The link ( http://jaguarpc.com/forums/showthread.php?t=13182) in point 9 doesn't work.

This is probably it...

Email woes

...or not.

Hrm...

A puzzle! I'll have to see if I can find it now.

[Dab]

Email woes

...or not.

It's "or not." In the thread you refer to, the same link is posted by Masood in his post #26. The link doesn't work there either.

[Vin DSL]

Nope definitely missing, if I'm thinking of the same thread...

I think that's the one that Jag started, issuing a challenge for someone to come up with a better way to secure mail forms, and ended up with me rewriting the Feedback and Recommend Us modules for PHP-Nuke.

Hrm...

Maybe Rob, Ron or Connie deleted it...

[Vin DSL]

Heh!

Good old Google Cache...

http://209.85.165.104/search?q=cache...ient=firefox-a

[matthew]

All good points. I'd add the following.

19. Sysadmin installs and enables mod_security (can be done via WHM), and maintains a list of popular strings that hackers look for.

20. Sysadmin mounts /tmp with the noexec option.

I'm only new here, so I'm not sure if these are being done on shared servers already.

[JPC-Masood]

mod_security is not of much use.

Yes, /tmp is already secure on shared servers.

[mak4web]

Thanks