Security Issues

posted on 7:46 PM, November 14, 2008

We are often asked, "Is ExSite secure? Can hackers break in?" It is normal for people to want to know that their website and data are secure from theft or vandalism, but the subject of security is much more complex than these questions imply. We obviously design the system to prevent unauthorized intrusions, but there are many ways to cause mischief on the web, and software security can only deal with a limited subset of these.

In other words, Web Security has many facets. Let's discuss each of them in turn, and consider how ExSite deals with each.

1. Can unauthorized people access private pages?

Private (member-only) pages are protected by a login and password scheme. Normally you need to know a valid login/password pair to gain access to the private page.

There are two ways to "hack" into a private page. The first is to use technical hacker tricks to bypass the system security and fool the system into letting you in. Obviously we design ExSite to make this as difficult as possible.

The second way is to just to log in like any other user. The hacker's trick here is only in guessing the right password to use, and this is usually much easier than one would think. A disturbing amount of the time, the following simple tricks will get the job done:

use a password the same as the login ID
use a common, generic password like "password", "test", etc.
use common names (eg. the users' spouses or children)
use a variation on the login ID, such as replacing some letters with numbers, or spelling the login ID backwards

Some organizations issue stock passwords, such as login + member number to all their users. These are also easy to guess, once you know the password formula.

The lesson here is that if you do not select hard-to-guess passwords, no amount of extra system security will help. Worrying about engineered security at this point is like investing in the most expensive, hard-to-pick locks in the world, and then keeping your key under the doormat.

ExSite does attempt to enforce a basic password strength policy when users change their own passwords, to prevent weak passwords from creeping into the system. This is described in more detail below. However, these tests can be bypassed when doing bulk imports of member data or login accounts. Be sure to use reasonably secure passwords when initializing new accounts (eg. a random text string). If users then attempt to change their password to something that is easier to remember, the built-in password strength feature will ensure that easy-to-remember is not the same as easy-to-guess.

2. Can unauthorized people access administrator screens?

The administrator screens will only display information to users of a sufficiently high access level. You must be at least access level 3 to set other users' access levels.

Under-privileged users will have their access denied, and will get a login screen instead of the administrator screen. This has all the login and password strength issues noted above.

If you are making good use of the password strength feature noted above, your administrator passwords should be relatively secure from password-guessing programs.

3. Can unauthorized people access the server or database back-end?

This falls outside the realm of ExSite, and in the broader area of server security. Suffice it to say that ExSite does not require any server or database services be opened up to the general Internet, and for maximum security we recommend having nothing but the minimum required services opened to the Internet. In the minimum case, this is http (and/or https) only, but in many cases you will also need some other basic services such as ssh to connect to the server for remote maintenance. Common legacy services such as ftp, telnet, and sendmail should be disabled if possible, as they are a known source of many security issues and are not used by ExSite at all.

4. Can communications with the website be eavesdropped on?

Eavesdropping usually occurs in one of two places: (1) over the network, and (2) at the user's keyboard.

The first case has a straight-forward solution, if it concerns you: run a secure (encrypted) server (https). ExSite supports this mode of operation.

The second, more devious form of eavesdropping, is a more serious problem. Malware (viruses, trojans) that infects PCs may install "keyloggers" that watch what you type, and record the information for their own use. Using a secure webserver will not help if your users are using PCs that are infected with keyloggers. In some ways, this is a more likely and imminent threat than someone eavesdropping on your network connection, since (A) many people have infected PCs, and (B) you have no control over what PCs people use to connect to your website. Since the problem is out of your hands, you should simply assume that this is the case for a small proportion of your users, and take steps to mitigate the possible damages (see below).

5. Can the website get vandalized ("defaced")?

Defacing websites is a popular pastime in some hacking circles. Essentially, hackers plaster their graffiti on your home page as a way to gain status amongst their hacker peers.

To deface a website, they need to get administrator access in some way, either through your web application, or through some other weak point in the server. These methods of breaking in to your system are already covered in points 2 and 3, above.

6. Can the website become inaccessible due to a denial-of-service attack?

A denial-of-service (or DOS) attack swamps your website with so much traffic, that it can no longer respond to legitimate requests.

Because there are never any unauthorized intruders in your system, it may help to think of this as a performance issue rather than a security issue. Ie. the problem is not that your server has been breached, but that it cannot keep up. You can deal with this the same way you deal with too much traffic in general, eg. (1) switch to a higher performance running mode, (2) switch to faster server hardware, (3) use more static pages, which are faster.

Of course, a real DOS attack can always increase its bogus traffic to match your increased performance, so this isn't always a fix-all. It would be nice to be able to ignore or downgrade bogus traffic so that it has a lesser impact on your system. ExSite has some built-in kill-switch features that can help. There is a manual kill-switch that blocks all dynamic page views (the most costly form of visit) so that when under the effects of a DOS attack, only your static pages will be served. Alternatively, you can have a kill-switch trigger automatically when the server is too busy. Regular readers will get a friendly message telling them that their page view has been delayed.

If DOS continues to be a serious problem for you, then you will want to look into dealing with the problem before it even hits your website, such as at the webserver level (Apache) or at your firewall. Note that DOS attacks (and their even more serious cousins, distributed-denial-of-service attacks) can be quite difficult to handle even for the largest professional websites. There are no simple solutions for this problem that don't also impact real site visitors, unfortunately.

7. Can members' personal data be viewed by unauthorized people?

Only if you allow it. Member's private data is normally handled by a Members or Membership plug-in.

If privacy of member data is a concern, then the Best Practice is to use this plug-in on member-only pages, so that only authorized users have access to it.

Otherwise, you can put the data where ever you choose. For example, some sites may be promoting their member's products or services. Those members probably want you to publish their contact information where everyone can see it.

This is an issue that should be taken into account in your site's Privacy Policy—be sure to inform users how and where their personal data will be shown.

8. Can sensitive personal data (eg. credit card numbers) be viewed by unauthorized people?

See point #7 for a discussion of how personal data can be handled. ExSite does not collect sensitive personal data like credit cards by default.

Best Practice is: simply don't do it. There are many reliable, secure e-commerce services out there that will take on all the security issues and risk associated with handling credit cards. Outsource the payment processing to these services, and the whole problem is out of your hands.

If you absolutely must collect and store sensitive personal data, then you should have a protocol for handling that data, such as:

encrypt the data while it is in transmission
encrypt the data while it is stored on disk
delete the data as soon as possible after collecting it

Mitigating Security Risks

Transforming any website with regular user accounts into a fortress that is impervious to hackers is a fool's mission, because:

users will want to choose weak passwords
users will re-use similar passwords as much as possible on different sites
users will access your site from infected PCs that will steal passwords
access to restricted functions is only restricted by a login form, which has all of these weaknesses

If anyone can reach the login form, then your site is only as secure as your login and password policy. Anyone, including automated robots, can type into your login screen, which means anyone who has stolen a password, or is willing to try a bunch of guesses, can take a crack at it.

Implementing a truly secure password protocol and security regime is not that difficult, but it can end up being so user-hostile that your users won't be able to figure out how to log in because their passwords are too difficult, or constantly changing. The benefits of higher security may outweigh the risks.

If convenience to casual users is important, then it will not be easy to implement a truly secure system. In this case, a more sensible approach is to be aware of the security risks, and plan to mitigate losses or damages due to security breaches:

Implement reasonable password strength requirements. (See point #1, above.)
Limit the amount of data that is exposed to individual users. That way if a normal user's password is compromised, only that one user's personal data is put at risk.
Make regular (eg. nightly) backups of your database, so that you can do a complete recovery of your site if it becomes seriously damaged. In most cases, the database alone will let you rebuild the entire website, because the archiving functions of the CMS will let you rebuild and republish all of your pages.
Outsource all truly sensitive data handling (like credit card processing) to 3rd-party services that specialize in managing those security risks.
Have a rigorous security policy for your admin users, to minimize the risk of admin passwords being compromised: have a strict password policy, and ensure that the computers of website administrators are disinfected and free of malware.

Hardening ExSite

Here are some steps you can optionally take to add extra security to an ExSite installation or its webserver.

Run a secure server with an SSL certificate.
Store passwords hashed or encrypted (but see below for comments).
Increase the required password strength, as noted above in point #1.
Add an .htaccess file to restrict access to key administrator programs such as login.cgi, home.cgi, and ctrl-panel.cgi. For example, you can restrict access to the admin programs to a whitelist of IPs.
Do not expose your database (MySQL) service to the Internet. Even better, move MySQL to its own server on a private subnet.
Do not open any unnecessary ports on your server. In particular, turn off older, insecure services such as telnet and ftp.
Disable PHP. PHP applications are a source of many security issues, and if a server scan reveals that you support PHP (even if you aren't actually using it), you may alert security scanning companies and hackers, flagging your server for extra attention.
Do not use member logins at all, if possible.
Avoid using obvious high-privilege login IDs such as "admin", "root", "system", and so on.
Do not use dynamic pages. If some pages have continuously changing content, see if you can republish them at a high frequency instead of generating them dynamically.

Additional Notes about Password Strength

ExSite has a password strength testing feature that is used when users change or update their own passwords. It will disallow passwords that are too weak. Password strength is calculated as a number on the following scale:

<0 is very weak
0-1 is weak
1-2 is OK
2-3 is fairly strong
>3 is strong

This scale is designed so that it can be compared directly to the users' access level (1 for regular users, 2 or 3 for administrators). By default, a password's strength should be greater than or equal to the user's level. For instance, a system administrator with access level 3 should have a password with a strength value of 3.0 or more.

Password strength is increased by:

using more characters
mixing letters, numbers, and punctuation
using mixed case
avoiding dictionary words

For example, the naïve password "password" is very weak because it follows none of these practices. However, "pA55-w0rd!" is very strong because it follows all of them (and has more characters as well).

If you want to change the strength requirements for passwords, use configuration settings like the following:

# decrease minimum password strength for regular (level 1) users
auth.password_strength.1 = 0.5

# increase minimum password strength for system administrators (level 3)
auth.password_strength.3 = 4.0

Note that password strength is only tested when passwords are set through normal password-changing tools in ExSite. If you manually set passwords in the database or through a data import, no strength tests will be performed, and the passwords will work regardless of how strong they are.

Additional Notes about Password Security

Passwords are stored in the ExSite database in plaintext by default. In some applications this is considered a dangerous way to store passwords because if someone gets access to your database, they get all of the passwords of everyone in the system, including the system administrators.

Our point of view is that if they have access to your database, it's already much worse than that. Encrypting passwords in the database is therefore false security. However, this extra layer of security is useful in some special cases, so ExSite has options for more secure password storage, which can optionally be enabled. For example, you may not want your IT people to browse the database and see passwords, or you might export your member data to files that are used outside the website, and you may not want passwords to be clearly visible in these exports. (You could just exclude them from the exports, of course, but sometimes that gets overlooked by accident.)

The configuration setting password_storage_method can be any of the following values:

plaintext - the default.

crypt - encrypted with 2-way encryption, so that the original password can be recovered with the system decryption key.

des, md5 - 2 different methods for hashing (encrypting with 1-way encryption), so that the original password cannot be recovered. With these methods, even if the list of password data is stolen, the hackers will still not be able to log in. (Small consolation, in our opinion, since they would have to be in your database to get this list, so they are already several steps beyond logging in.) Also note that both of these encryption methods are considered somewhat old, and susceptible to certain types of attacks that are feasible with substantial, but feasible, amounts of computing power.

Additional Notes about Secure Servers

Running a secure server (https) is a simple way to encrypt all communications with the website. This prevents eavesdropping on the network, but not at the user's PC. It is not a perfectly secure solution, but with certain types of data, especially sensitive private data, the risks are high enough that you want all the protection you can get.

Do you need a secure server? Ask yourself: what are the consequences of someone being able to see data entered into forms, or data returned in pages, as they are sent over the Internet? If the consequences are not serious (eg. someone can see that you ordered yellow towels), a secure server is optional. If they are serious (eg. they can see that you ordered yellow towels with credit card number XYZ to be delivered to your home address at ABC) then it's a good idea.

The simplest way to set up a secure website is to serve the same site from both a secure and an insecure URL. That way, if anyone types in a URL and uses http: instead of https: they will still get to the right page. However, if you ensure that all links on the site itself always point to the secure version (https), then no matter whether they start from a secure or insecure URL, they will always end up at a secure URL after they follow any links or forms.

To make sure that all links point to the secure site, you should do one of the following:

If it is the root section on the system, manually configure the system to use the secure URL in exsite.conf. Do not rely on autoconfiguration, which will maintain whichever URL the user came in from.
If it is not the root section, then set up the section as a "stand-alone" section, and define its full base URL (with the https:) in the section configuration.

Filed under: security, IT, programming