Fort Knox Is Child’s Play Compared To Web Security We Offer

QArea Team by QArea Team on December 1, 2015

Fort Knox Is Child’s Play Compared To Web Security We Offer
Reading Time: 4 minutes

How would you feel if one day you try entering your own business website and it’s gone? Completely. Without a trace. A complete zero instead of its former glory. You would feel devastated at the very least, right?

And it can be worse. Your site can still be there but with unappropriated content, Viagra ads or anything of that sort. A painful strike to your entire brand. Your visitors, YOUR CUSTOMERS saw something horrible. Do you think they will trust you with their data after such an occasion?

It can be even worse than that! Hackers might actually steal data from you. Both business- and customer-related information. Credential, account details, etc.

Estimated damage from hackers is undeniably uncharitable.  Let’s take small and medium businesses in the US for example. They suffer from financial loss of $8.700 per business on an annual basis. All that because they’ve failed to ensure decent levels of security on their sites.

According to a survey conducted by the National Small Business Association in 2013, a total of 44% of small businesses have suffered from attacks. Forty four percent. That’s almost a half! Seven million businesses were attacked during the summer of 2014. Can you imagine the impact and the scale of these threatening events? Can you imagine the level of terror we are under while online?

Better safe than sorry!

Here are several other intriguing numbers. According to National Security Alliance one of every five small businesses gets hacked in one way or another. 60% of these companies are out of business after the incident. Permanently.

What does that mean? You, personally, are in the risk zone. There’s a huge (20%) chance your company’s online resources will get hacked next. And the assault may result with your beloved business absolutely demolished. Quite the risks, don’t you say?


Playing it safe: World’s best guidelines

First thing first. Consider Drupal as your primary CMS. After all, if it’s good enough for, it is destined to do the trick for your site as well.

Drupal has an insanely large community of dedicated developers behind it and is backed with constant thirst for improvement and innovation. Thousands of people work on improving its security day and night. Literally. That’s why it is so good.

However, simply relying on your primary CMS is definitely not enough in terms of your online presence protection. Here are several tricks from our personal arsenal that might help you out:

  • Prevent XSS. Malicious code inputs (injections) have devastated thousands of websites so far. Here is how you do it:
    • HTML utility combined with Formattable Markup (they have replaced check_plain in Drupal 8) are a great means to ensure special characters in a string of plain-text are encoded and, more importantly, UTF-8 strings are validated. This method is insanely efficient in preventing cross site scripting attacks.
    • Filter_xss. This function, as you can see from its name, filters HTML in order to prevent XSS (cross site scripting).
    • Filter_xss_admin. This is an insanely powerful HTML/XSS filter that can only be used by the admin. It is mostly used in areas where something like check_plain is impractical or unacceptable when applied to a whole filter system.
    • Check_markup. This function is designed to flawlessly run all of the filters you have enabled on specific pieces of test (potential injections).
    • The t() function with % or @ placeholders is a means for translating strings into a current or given language.
  • Your database should use an abstraction layer. This way, numerous threats SQL injections present are dealt with by default. Here is a tip:
    • The wrong way to do it:
      db_query('SELECT bar FROM {table} t WHERE t.nid = '. $_GET['nid']);
    • The correct way to do it:
      db_query('SELECT bar FROM {table} t WHERE t.nid = :nid', array(‘:nid’ => $_GET[tid]));
    • And, if it’s the dynamic queries we are talking about:
      db_select('table', 't')
          ->fields('t', array('bar'))
          ->condition('t.tid', $_GET[tid])
  • The Drupal API form requires appropriate treatment:
    • $form_state[‘input’] should not be used. It’s the raw POST data, after all.
    • And, speaking of the devil – don’t operate with POST data in your submitters and validators. If you wish to maintain your site safe and sound, that is.
  • Don’t ever allow users to upload files that are in the *.* format.
  • Pay attention to Javascript. Here are several smart restrictions for you to follow:
    • Never rely on JS for validation purposes. Users can easily disable JS.
    • You can’t afford an assumption that all data, while sent to AJAX postback functions comes from your own JS function.
    • Same goes for the belief that data, when sent by or to a JS function is hidden well and cannot be observed by a user.
    • There are DOM functions capable of decoding HTML entities. Never reinsert such functions into your pages without escaping.
  • Doubleno!triple-check all of the site’s permissions for each group of users.

Sequrity guideline

The last but not least

Always keep your Drupal version updated. Its core, modules and the functions. There is an entire community dedicated towards finding and fixing possible vulnerabilities of Drupal. Vulnerabilities hackers are or will be using against you.

If you don’t keep Drupal updated and your site properly maintained – all other efforts are pointless.

And, you know what they say: Better safe than sorry, right?

Check out our related articles:

Security Is Not A Game! Or Is It?

OR: Protecting Your Right for Anonymity

How to use a natural language terms of security information?