• Thursday, 01 January 2009 00:00
• Last Updated Thursday, 26 November 2009 17:37
• Written by Dan Knauss

In the summer of 2008, Drupal, Joomla! and Wordpress--the three most popular free, open source online publishing engines--made it onto IBM's top 10 security vulnerability list.

IBM's report noted that:

...a commonality between these three vendors is that they are all written in PHP. If we look back over last year's disclosures and apply the new CPE [Common Platform Enumeration] methodology to them, we would uncover another newcomer to the top five list, PHP itself, which would rank number four in the 2007 top five vendors.

[Source: IBM Internet Security Systems X-Force® 2008 Mid-Year Trend Statistics]

This report may sound as if it is suggesting there might be something inherently wrong with Drupal, Joomla, Wordpress, or PHP, but any networked system can be exploited. It is mainly Drupal, Joomla, Wordpress, and PHP's popularity under open source licensing that has made them security-risk peers of major web software vendors such as IBM itself, Microsoft, Apple, Oracle and others on IBM's list.

Drupal, Joomla, and Wordpress use other underlying (server-side) open source technologies: PHP, mySQL, often Apache, and often a Linux or other *nix variant. Known as the LAMP stack, these systems drive the majority of the world's webservers due to their quality, popularity with programmers, and free, open source status--which drives their quality and popularity. Wide implementation of these tools and easy access to them makes for a lot of targets.

In the open source world, security problems, like program bugs, are not hidden--they are wide open to the world. They are also rapidly, intentionally, and directly exposed to the public so that security solutions can be found and quickly disseminated. People who miss an alert to upgrade or patch a newly discovered vulnerability are probably the majority of those who fall victim to attackers.

This document explains some essential ways to keep your PHP/mySQL applications safe, but the fundamental rule in a nutshell is: keep your software up to date.

New Local Media follows its own advice (as given on this page) with every website it builds. Some of the precautions and practices, however, require site owner/operators' ongoing awareness and proactive, pro-security efforts.

Making Your Website and Other Networked Software Secure

Disclaimer: This is not a comprehensive guide; it doesn't cover things like SSL and secure/encrypted transactions in any depth. Moreover, while this document treats "security" and "vulnerability" as "software" or "technical" issues, that is not how they should be fundamentally understood. In a world where wet washcloths open million-dollar security doors, everything online is connected, and needles in haystacks can be found by googlehacking, there is no such thing as total security. It is more of a question of how easy you are to find and how much information you freely divulge--often unwittingly and unwisely--about yourself and your networked systems. [See Johnny Long's presentation to DefCon "No-Tech Hacking, or the Ninja Skilz of the Underground."] For example, if you write your passwords down or they can be easily guessed, no technological barrier will help you if an unauthorized person acquires this information.

What's the Worst That Can Happen? The answer to that question depends on your website. How much sensitive data and information is on it? (If it doesn't need to be there, don't keep it there.) The worst that can happen is that a really insidious cracker gets into your mail server, file system, and/or databases and--unbeknownst to you, starts using your server to 1) send out a lot of spam, 2) host his own code or webpages, likely illegal or otherwise unpleasant material, 3) conduct attacks on other sites or intercept data passing through forms and other parts of your site. Or the cracker could do all of the above. This is all really bad, with really bad consequences for the victims--you and people visting your site.

Fortunately, the worst that typically happens to very simple sites (ones that are not storing or making external connections to transport sensitive--e.g. financial--data) is usually little more than vandalism--someone defacing the site or deleting things on it. However, the vandals might also leave a backdoor to do this again, so a clean sweep and restoration of well-kept backups will rapidly fix this. (If you have no good backups, you're screwed, and you bought low-quality hosting.)

I've only seen one incident of vandalism on a site I built that was subsequently left adrift by the owners without anyone maintaining it. A necessary update to a third-party software extension for the Mambo CMS had a vulnerability, an exploit was discovered and published about that vulnerability, and several upgrade cycles that would have plugged the hole weren't made. Eventually some Turkish script kiddies found the hole when they went on a graffiti rampage. The vulnerable extension had a file upload system that could be exploited to upload anything, such as a file manager script. That's what they did--which then allowed them to do anything to the file structure of the site, and they probably could have killed the database too if they had wanted to. All they really wanted to do was denounce Sweden, so they looked up easy targets and quickly nailed a lot of sites to make a political statement. The harm they did was merely cosmetic. It took minutes to diagnose the problem, restore the site, plug the hole, and weed out the scripts the crackers had uploaded.

What took more time and the problem is this: to be sure you were merely vandalized you need to be able to perform an audit or simply wipe everything and reinstall from a known good backup. However, a really insidious hacker may have taken the time to compromise your backups well before you detected his presence--depending on how you create and store backups.

Conclusion: It's best to maximize your security from Day 1 and plan out the recovery process. Here's how:

1. Acquire the services of a webmaster and/or server administrator who already knows most of the things in this document, or else take the time to learn it yourself. (All you need is a search engine and time.) If you feel you lack the time or ability to do this work yourself, learn the basic concepts and get good help. If you can't do that, ask yourself, do you feel lucky?

If the security learning curve seems pretty steep and you don't want to climb it, are you prepared to have your site broken, defaced, your and your users' private information stolen, your mailserver used as a spam engine, and who knows what kind of malicious scripts embedded in your site to infect you and your visitors' machines? Recovering from such disasters is a hard and serious chore since a truly malicious attacker will have left backdoors, covered his tracks, and/or compromised or destroyed your backups. It's a question of what your site is worth to you.

That's the worst case scenario. Generally speaking, it's unlikely you represent a target of high value or attraction to expert system crackers, so your main human enemies (other than yourself) are likely to be the hordes of net vermin known as "script kiddies." Script kiddies are the counterpart of the low-end amateur webmaster. Both are like the "dumb cows" in the "smart cow problem." All it takes is one smart cow to open the latch, and all the other cows follow her out the gate. All it takes is one smart software developer to make a web application that anyone can install and use by following a few instructions. And all it takes is one smart cracker to make malicious programs that anyone can use by following a few instructions. If you're the former, the script kiddies are the latter. To further extend the metaphor, the script kiddies are the dumb wolves who follow the dumb cows through the gates left open by the dumb cows--and sometimes the smart ones too. Ultimately this Darwinian process smartens all the cows, or eliminates the dumbest. If you'd rather not be thinned from the herd in that way, here's how to be smarter and safer than most website owners.

2. If you do not have a server administrator managing your own server, use a quality host:

• Who makes timely updates of the software your site needs to run. (PHP5+, MySQL5+, Apache, Linux, cPanel, Pleask, etc...)
• Whose webservers are running under a user with no privileges outside the web directory (except the tmp directory). If they have PHP running with suexec/suPHP or as a CGI or FCGI/FastCGI process, that's good. Suhosin is good. The common practice is still to run PHP as an Apache module, possibly with its safe mode turned on, which disabls a number of PHP functions you will likely need to built or run a site with a blog engine or CMS. There are performance and security problems with this, but a decent host will have or allow some reasonable methods to be employed to improve security.
• Who has Register_Globals and other problemati PHP functions turned OFF. Or, it's possible for you to turn them off. You can do this switch it off in .htaccess, httpd.conf, and/or php.ini. (If you don't have access to any of those files even on a cheap shared host, it's a bad host.) Register_Globals has been deprecated as a major security risk. See the PHP Security Consortium. Web applications that require it are obsolete and the product of sloppy, vulnerable code probably written for PHP4. As of PHP 4.2.0, register_globals defaults to off. If your host has it turned on, your host is probably hosting a bunch of lazily maintained or abandoned websites that use old software and an old version of PHP. These people may be on the same physical server as you. This is not an environment you want to be in. (Use phpinfo to find out everything about PHP on your server, including whether register_globals is on or off. Just don't make it possible for anyone else to run phpinfo on your server.) It's also good to have register globals emulation off, magic quotes on, and short open tags off.
• Whose shared servers aren't jam-packed with other users' insecure and/or highly trafficked websites. (Or don't use a shared server. Who's a good host? Here are my personal recommendations.)

Additional good qualities in a host:

• They are not a middleman or reseller--they own and maintain a quality datacenter--or as resellers they truly add value and do not just get in the way.
• They are committed to fast support response time, and their support staff shares fluency in your a language in which you are also fluent.
• They have competent server techs doing providing their support services. Added bonus if they are familiar or proficient in the main software you are using and build their servers to optimize its performance and security.
• They will run your PHP as CGI or suPHP on request or by default.
• They will do a lot of things for you and answer questions without getting cranky and demanding money.

Server Vulnerability Scanners and Analysis Tools Good for Assessing Sites and by Extension, their Hosts:

• Top 10 Scanners (2006) - (Try Nessus and Nikto) - Top 100 Security Tools - Also NMAP, Wireshark, Metasploit, Ping Sweep, Firewalk, and Angry IP Scanner.
• IBM Complimentary Security Health Scan
• NB: Network vulnerability scanners may be "unable to identify systems that have been updated using back-ported security fixes as the version numbers of the updated software does not change when back-ports are applied. In many cases the only way to externally test whether a service is vulnerable to a specific exploit is to actually test the exploit (not recommended on production servers) as this can directly cause service crashes and other unwanted side-effects" (MediaTemple.net Knowledgebase)

3. Know your enemies--the most common attack techniques on PHP/mySQL systems:

• Remote File Inclusion/Includes (RFI)
• SQL Injections (SQLI)
• Cross-Site Scripting (XSS)
• All of the above and more: http://www.cmswire.com/cms/web-cms/how-they-hack-your-website-overview-of-common-techniques-002339.php

4. On your local machines and local network--essential, minimum security practices:

• On your local machines:
  • Keep all machines that you use to operate your website secure--password protected, running a regularly updated firewall, spyware and antivirus scanner on a secure network, especially if wifi is involved. (Numerous high-quality, free firewalls and malware scanners are more than adequate if you know how to use them.) Don't get hijacked!
  • Keep all machines' software updated, especially browsers and operating systems. Your website(s) can get hacked because you failed to update your browser! This has happened, in one case it involved 40,000 sites in one day.
• Login ID/ and password practices all the time, wherever you are:
  
  • Don't use the same ID/password combos redundantly on websites where you have an account.
  • Know what a strong password is--and don't keep them recorded in places and ways other people can easily access. (Try the Mnemonic, memorable strong password generator)
  • Use unique login IDs and strong passwords for the root user, database users, FTP users, and admin accounts in web-based applications you install. If you use software that automatically establishes the first user account as a superuser with a certain login IDname (like "admin"), change it.
  • Change passwords immediately to lock out users when this is applicable, especially server, FTP and database accounts used by people providing technical support.
  • Create limited access accounts for people providing technical support. Always avoid giving out more access permission than is necessary.

• Stay Informed:
  • Read up on recommended security practices for the web applications you are using and keep abreast of them as they develop. Things change over time--overnight, actually. The pace of software development is often very fast.
  • Set up ways to be notified of updates for the software you use--and update your installed applications in a timely manner. (Get developer and security news pushed to you by RSS feeds, email newsletters, etc.)
  • Monitor relevant security bulletins from the people responsible for the software you use. Follow relevant industry news and specialized security monitoring services provided by firms such as Secunia.net and Vupen.com.
• On your server:
  • Remove installation files and folders after installation of web applications.
  • Remove software you do not use.
  • Know what software you have installed. Don't randomly install applications and add-ons without considering the source.
  • Update your installed applications (including templates/themes) in a timely manner, and make sure you understand how the updates relate to an individual site/installation. (NB: With Joomla, if there are updates to core template overrides, this may imply a need for you to make additional changes to your own custom or 3rd party templates if they use overrides based on the older core overrides. Brian Teeman explains this here.)
  • Only use quality software with at least a 1.0 stable release version. Do not use in-development software, alpha or beta releases, or release candidates on production sites unless you have a good reason to justify doing so. (Stop and think first.)
  • If you are using third-party software such as extensions for a CMS, determine who the quality providers are, learn to evaluate them and their code quality, and generally avoid using software that is not in active development. "Abandonware" is a big target for script kiddies, maybe the biggest.
  • Wipe out all files for unused extensions; sometimes uninstalling is not enough.
  • Lock down remote database access to the ISP or IPs/IP range you use. (Remember this will block you from getting in through another network or ISP.) Your host should not have remote db access open by default.
  • Use proper file permissions, generally 755 for folders and 644 for files, if not lower. (Disable all write access for critical config files that do not need to be changed once they are set up properly.)
  • Do not use default, typical, or easily guessed database prefixes.
  • Use robots.txt to keep things out of search engines that should be kept out, such as everything in your installed web app folders. Keep in mind that anyone can look at robots.txt and see what it is you want folders you want to keep out of the public eye. If you want to lock things away from both search engines and prying eyes, use permissions and/or password protected directories.
  • Keep adequate, timely backups in a secure location above/outside the webroot. Ideally your host is also providing various backup services. It's good to know how these work before you need them.
  • Keep essential config files to web apps above/outside the webroot, if possible.
  • SEF/human-readable URL aliasing can block hackers from seeing and meddling with your software in some cases. Unaliased URLS also disclose a lot of information about a site. So use URL aliasing.
  • No publicly exposed phpinfo.
  • Form filtering: contact and especially text-editor forms on your site are common gateways for trouble. Applications like Drupal and Joomla have filtering controls governing what different levels of users can post in forms, from simple text to actual scripts/program code. Do not give anyone more access than they need. Use strict and intentional, well-considered filtering policies.
  • In php.ini or .htaccess:
    
    • Turn register_globals OFF - deprecated and deeply problematic, should be off by default anyway.
    • Turn rg_emulation OFF - why emulate a bad thing?
    • Turn magic_quotes_gpc ON - if you are using older and less than ideal extensions that don't escape user input, this setting helps prevent bad guys from passing their payloads through forms and such. It's a better idea not to use risky extensions like that, or to fix their code. The Joomla core and the extensions it is distributed with escape all user input. magic_quotes has been deprecated and will not be included in PHP6.
    • Turn allow_url_fopen OFF - unless you haveareal need for it, disabling helps prevent bad guys from pulling a remote file include attack on you.
    • Turn short_open_tag OFF - short open tags are a lazy coding technique that's frowned upon and opens up some vulnerabilities.

5. Other strongly recommended practices:

• Make yourself articulate a justification for each exception you make to these rules. Exceptions are often necessary, for a variety of reasons.
• Change passwords periodically.
• With Joomla! and similar web applications, clear your tmp folder. Joomla! uses tmp to store extensions you've installed, or parts of them. Sometimes extension files remain in tmp after installation/uninstallation.
• Use SSL on admin and cpanel login pages and SSL/TLS for FTP, or other security protocols to avoid sending your passwords and login IDs over the web in cleartext. Use .htaccess to redirect all http:// requests to the login area to be redirected to https://. If any part of your site needs SSL for data transfer, the whole site needs SSL.
• Smashing Magazine's10 Steps to Protect the Admin Area in Wordpressis very useful and applies somewhat more broadly than just WP.

6. Other simple ways to harden your security:

• Use .htaccess to lock out use of CGI, Perl and other scripts if you never use them.
• Secure .htaccess from prying eyes. (One way to do this.)
• Use .htaccess to double lock (password protect) your web app login screens.
• Use quality server and client side security auditing and lockdown tools. There are many open source options, and many specific to popular CMS platforms. They will often do or check on many of the things covered in this list.make sure you don't leave diagnostic or evaluative software on your site where others can access it. If you're done with it, get rid of it.
• Make sure your log and temp files are not in public web-accessible folders.
• Block unwanted IPs at the server level using a firewall if you are able and find this helpful. Otherwise it is less effective but possible to use .htaccess to allow only designated ISPs or IPs to access the login screens. (Remember this will block you from getting in through another network or ISP also.) Lock out anyone you don't want on your site or in certain areas of your site. Blacklists can be used to lock out networks known to belong to crackers and spammers. NB: The .htaccess blacklist method is easily circumvented by using a proxy server, but it may be enough of a stumbling block to deter potential attackers like script kiddies who aren't desperately determined to nail you. Also, in some cases you really may want to dramatically reduce the size of the web for your site. If you are running an English-only community news site in Maine, it's virtually certain that most foreign traffic doesn't need to be there and may be up to no good. Block it, or watch out for it. This is pretty drastic and paranoid, but it may be a useful method when you can see or have reasons to expect an attack.

7. Security by obscurity:

Security by obscurity is not true security. It's camoflage, not armor. But camoflage can go a long way. If it works well and you're also lucky, your armor will never be tested by the bullets.

• Remove, hide or rename files and other common identifiers that reveal the identity of the software you have installed, such as the meta-generator tag and copyright or "powered by" taglines. (Sometimes these are not visible to you on the page but are embedded in the underlying code in a comment.) Announcing your CMS brand and version number--particularly when it is not up-to-date is often all that an attacker needs to know.

• If a web application is well known to have an administrative login screen in a certain folder, rename that folder or use redirects to block direct access to it. You could also make it password protected with .htaccess. Obvious entry points like this are ones an attacker can fish for or locate in a search engine. Even small design details common to a specific application may imply or suggest version information.

• Disable the PHP functions that make its identity and version evident, as well as those that control error displays and reporting since this information can help an attacker acquire a vulnerable target on your site. Make sure your error logs are secure and perhaps stowed in an unconventional if not publicly accessible location, and give them an unconventional name.

Also of Note:

• A sample of an .htaccess file for hardened security with Joomla (but broadly relevant to other applications too) from corePHP.
• Sound Security Tips for Joomla! Installations from Rochen Performance Web Hosting.

Brian Teeman covers some key Joomla security tips in this video: