Third Party Applications

Using third-party scripts which are often downloaded for free is a great way to add additional functionality to your website. The downside is that you are installing software often from an unknown or untrusted source and of potentially unknown quality and security on your server and giving it access to your web hosting account. If the software is well known (or old) then it is possible that it contains security holes that will be used by malicious third parties to access your data, deface your website, or send spam.

When using third party scripts, we recommend the following safe practices:

• Download scripts only from the official website of the software author, or from a well-known reputable source. This will minimize the chances of you loading a script with malicious content. The same applies to plugins for well-known apps such as Joomla or WordPress.
  
  
• Always download the latest version of the application and its plugins - never reuse code you have downloaded before as security exploits may have been discovered and patched in the meantime. Never modify an old application for a new site - always start with the latest.
  
  
• Monitor the official website of the application developers constantly - if they have an announcements list or forum then subscribe to this. Most well-known applications are updated with security patches every few months or immediately if an critical flaw is discovered - if you do not keep up to date your site *will* be compromised. Again - this applies to plugins as much as it does the main application.
  
  
• If your site was developed by a web designer, ensure that they have used the latest versions of all scripts and that you have a maintenence contract in place to ensure that scripts are updated regularly.

The following well known scripts have all had serious security holes found and exploited in the recent past. It is essential that you run only stable patched versions of these programs and their plugins and keep them updated ...

phpAdsNew, phpBB, formmail.pl, phpMyAdmin, phpNuke, DotNetNuke, phpGroupWare, Mambo, Joomla, Drupal, Geeklog, Moodle, WordPress, vBulletin, Phorum, Coppermine, SugarCRM, osCommerce, zenCart .... and many many many more!

Your Own Applications

Writing your own applications gives you ultimate control and flexibility in designing your website. However unless you are a proficient programmer and are well versed in secure coding practices, your code may be used by malicious third parties to access your data, deface your site, send spam or attack other websites.

Many programmers believe that because their application is custom written and not well known, then it is less to be targeted or exploited. Our experience is that this is a false assumption - it is very common for user-written scripts (especially those that implement contact forms, guest books or mailing list signups) to be hijacked. Attacks on such scripts are performed by automated systems that scan your website, harvest email addresses, and probe all forms and scripts on your website.

The cardinal rule in writing secure applications is never to trust any input submitted via a web form. All data submitted should be submitted to rigorous validation and sanity checking before it is used by the application or passed to any external program.

The most common exploits performed on user applications are:

• Using the message body or other fields in a mail form to inject headers that fool the application into sending spam to hundreds of email addresses at a time (be really really careful what you pass to sendmail or PHP's mail function). Use CAPTCHA's to prevent automated accesses to your forms.
  
  
• Using simple content management scripts, usually something like index.php?page=mypage.html to access external content and to pass malicous commands to PHP or to the underlying operating system, or to view normally hidden files. You must sanity check that only filenames you specify can be fetched.
  
  
• Accessing non-initialised variables in an application to pass malicious data or commands to PHP or to the underlying operating system (initialize absolutely every variable in your script to a default value even if its just blank or zero, then use $_GET or $_POST (in php) to load any form variables, finally check check check the values for validity, then check them again!). Do not use or depend on php's Register Globals function. If your host has disabled this, do not use methods like extract() to get around this - it was disabled for a reason!
  
  
• Injecting SQL commands into form or query variables that are not correctly parsed and/or escaped. Unsanitized variables being passed to SQL queries are the number 1 source of site defacement, customer information disclosures etc. 

We recommend that before you write your own scripts, you should familiarize yourself with safe coding practices for web applications. The following references may be useful starting points:

• Developer.com - On the Security of PHP Part 1
• Developer.com - On the Security of PHP Part 2
• PHP Foundations - PHP Security 1
• PHP Foundations - PHP Security 2
• PHP Foundations - PHP Security 3
• Top 10 Most Critical Web Application Security Flaws