How to Protect Your Site from Being Hacked

How to Protect Your Site from Being Hacked

To say the issue of security is as old as the digital age itself would be a drastic understatement. The need for security is as old as civilization. But with the digital age, the responsibility has fallen to more people than ever before. One notable case is site administrators, in other words people who manage websites. While it's important to keep things secure, may people have some pretty major misconceptions about how sites get hacked, which are perpetuated by Hollywood movies and are constantly paranoid that any nerd can instantly gain control of their site. Many more, sadly, don't do enough to keep their sites secure from malicious users. 

Protect your password

When it comes to gaining unauthorized access to your site, the most obvious way to do it is the way it was intended; by using a password. Chances are if you've been on the internet, you've heard about password security time and time again. You might get tired of hearing the same message over and over, but this it's definitely an important message because unless somebody comes up with some magical alternative to using passwords, they're here to stay.

One of the most common ways for hackers to gain access to your site is by stealing your password. This avoids any need to subvert the system they're trying to hack because they're using the system as intended. This is also one of the worst ways for your site to get hacked. In this case your hacker could change your password, along with the email address associated with your account, locking you out. This is far from the worst case scenario, and could in fact be a good thing since you'll (hopefully) know right away that something is up. A user could just as easily keep your password the same constantly steal information from your site or make subtle changes to your content that you don't notice right away.

If you have FTP access to your site, it's even more important to keep this locked down. FTP stands for File Transfer Protocol. It's used to transfer files to and from your site. Most sites are made up of a set of files and a single database. If somebody gets access to transfer files to and from your site, they have complete control of your site until it gets resolved.

So the bottom line is, protect your password. I could go into more detail about this but that's a tale for another time, so here's a quick list:

  • Avoid sharing your password as much as possible. Also avoid sending passwords through email. Yours might be secure, but you can't always be sure of the same for whoever you're sending it to. The more you share your password the more likely it is to be stolen
  • Long passwords work better than short ones with jumbled letters. X9)#JaRpn5 is not as secure as ThisLongPasswordWithoutSpecialChars
  • Use 2-factor authentication if possible (To much to explain in a bullet point, but here's a useful reference from Google: https://www.google.ca/landing/2step/)
  • Above everything else, keep your email secure. If a user can access your email address, they can access just about anything that you've used your email to register to. One of the most common mistakes people make is registering for a service using the same password they use for their email.

Social Engineering

"Social Engineering" is just a fancy way of describing how people try to trick you into giving them access. This involves a hacker contacting somebody who can give them access to whatever they're trying to hack and making up some story about how they need access immediately and often involves a tragic tale of how they'll lose their job if they don't get access. Or perhaps they're your supervisor who you've never met that's trying to convince you that YOU will lose your job. Sad though it may be, this is the most common way for hackers to get access to your site.

If you're a site administrator, you probably only have a few trusted staff/co-workers who have administrative access. This means that a hacker would likely need to convince you that they're one of these few employees. The bottom line: be careful about who you give passwords to.

Generally social engineering attempts are aimed towards technical contacts such as hosting providers. I'm talking about people who have direct access to the file and database that comprise your site, and possibly people who have control over your DNS (that's what makes www.yoursitename.com actually point to your site). These people are trained not to fall for social engineering scams, but sadly they happen, and there's not a lot you can do about it if they do besides choosing a trustworthy hosting provider.

Actual hacking

Hollywood paints an interesting picture of what a hacker looks like and how hacking actually works. Usually it's a thin, pale nerd living in his mother's basement with a prodigious collection of comic books, vintage video games, magic the gathering cards or something else nerdy. The hacking attempt usually involves furiously typing with ones and zeroes flying across the screen, or windows popping up in rapid succession. This can be exciting to watch in movies, but it's far from how hacking takes place in real life.

In real life, however, hackers work by exploiting vulnerabilities in a system's code. When it comes to your website, in most cases the hacker knows about a particular vulnerability beforehand. In most of these cases, there is an available update to patch the security flaw but it hasn't been patched on your site. It is possible that a hacker could find a vulnerability that is not known to the system's developers (by System I mean Content Management System, hosting provider, etc.) but it's unlikely. Usually hackers become aware vulnerabilities when patches are released. Basically a companies like the ones who created Drupal and WordPress find a bug and release a patch, informing which informs the community at large, which means potential hackers are made aware. At this point there's a brief window while sites are being patched where systems with this bug are vulnerable. This means that when there are available security updates for your site, you should update as soon as possible.

If you're a site administrator, you may see a message like this:

  • There is a security update available for your version of Drupal. To ensure the security of your server, you should update immediately! See the available updates page for more information and to install your missing updates.
  • There are security updates available for one or more of your modules or themes. To ensure the security of your server, you should update immediately! See the available updates page for more information and to install your missing updates.

This particular example comes from Drupal. When you see this, you should update your system as soon as possible. Of course, it's possible that you see this message, upgrade your system like you should, then see it again two days later because another update was released. If you're using a platform like Drupal which has many contributed modules, this can certainly happen since each module is maintained by a different party who may need to release a patch at any time. In most content management systems these messages don't come with a description of what the issue is or how urgent it is that you update. Fortunately, a tech-savvy site administrator can check the patch notes for a new update to decide whether a certain update is necessary.

A good example actually comes with Drupal 7.41 which is the most recent version of Drupal 7. According to the patch notes, this update comes with a patch for a security issue with the Overlay module. If you run into this update and find out that you're not actually using the overlay module, you can happily ignore this particular update. Keep in mind though that the pesky "There are security updates for your version of Drupal" message won't go away, nor will it change when new updates are released, so you'll have to check the most recent version or Drupal yourself from time to time to make sure there aren't any new updates.

Why there are security vulnerabilities

You might be wondering why these sorts of vulnerabilities exist in the first place. Here's the short version: Computers are complex. I'll elaborate here.

Imagine you have something you want to keep locked up. You might do this by locking it up in a box. For the sake of argument, we'll say this box is indestructible so it can't be smashed open to retrieve its contents. If some unsavoury individual wanted to see what was in the box, they would need the key assuming you kept the box locked. In this case, the system is so simple that there's only one way to get in.

Now imagine that whatever you're trying to keep locked up is in an apartment with a front entrance and a ground entrance with a lock. This is a slightly more complex system because there are now two ways in. Now let's say your goods are locked in a house with a front door, a garage door, a balcony door on the back and a ground level door in the back. Again there are more doors that you'll need to remember to keep locked.

Obviously a content management system is far more complex than a house, so keeping things secure is a lot more complicated than locking a few doors. To put things in perspective, a base Drupal installation has over a thousand files, with each of these files containing a few to a few thousand lines of code. Take the database.inc file found in the includes directory of a base Drupal 7.31 installation. This file has 3042 lines of code including a few blank links, a few single '}'s and this little bit:

foreach ($data as $i => $value) {

This line is taken out of context and is about as generic as a piece of code can get -- if you're a programmer yourself you may have seen something almost exactly like it dozens of times. How here's the same line of code but with a subtle change introduced in Drupal 7.32 (one version later):

foreach (array_values($data) as $i => $value) {

It doesn't look like much, but this tiny change made the difference between a secure version of Drupal (7.32) and all versions of Drupal that preceded it. Before this small patch was applied, all Drupal sites were basically a free for all for anybody who wanted to access whatever data was stored in the site's database. This meant that credit card numbers (which were encrypted, at least) were ripe for the taking, and anybody who knew how could gain full administrative access, all because of one small mistake in file with over 3000 lines of code among over a thousand other files.

Nervous?

This may be unsettling, but keep in mind that the same thing that makes it hard for developers to avoid these sorts of mistakes also makes it hard for hackers to track down. As I mentioned earlier, most of these types vulnerabilities are found by the companies that develop them and this particular flaw was no exception. This only became a real problem once Acquia released the security patch and urged people to update, which made hackers aware of the opportunity. Naturally this wasn't a problem for sites that were updated immediately, but for the ones that weren't, the longer they were left unpatched the more likely they were to be hacked.

So that's about it. Keep your passwords secure and your site up to date and you've done everything you can, and likely everything you'll ever need to keep it out of the wrong hands. Easy enough, though perhaps not quite as thrilling as the movies would have you believe.

To learn more about how websites are hacked and how to defend against hackers check out our High Five Episode "How can your website get hacked?"

 

 

Drew Ingram
Contributed by

Drew Ingram

, Software Developer
Up Next:

How Drupal Commerce is Creating the Best Ecommerce Checkout Flow

Next Article
Get Free Widget

Fields marked with * are required.

×