Save $45 (!!!) with our November discount

Hello again,

For the whole November we offer 25% discount for professional website security testing (valid for both plans). This means you save $23 or $45 respectively..

Use discount code: WEBY2013NOVE

Don’t let the bad-asses ruin your website. Be ahead! It is a great time to order website security testing from our website.

Cheers,
David

How to exploit a website which is not updated

Persistence is cool sometimes. Not when it comes to common sense though.

We could shout a million times that updating is critical, but the persistent ignorance would dominate. It’s not only about the websites – the same applies in every system – windows security fixes, internet browsers updates, adobe software fixes, Linux updates and of course – website CMS updates.

In a blog post Why Using Joomla Or Drupal Is More Secure Than Any Custom Made Application we said that using open-source CMSes could be safer than using some custom coded ones, but you should keep them updated.

And this is the biggest problem. Owners (authors, developers, etc.) care too much about the content, about the visitors, about SEO that there is no time for doing security checking and updating. It’s boring, it’s not worth it, we don’t see monetary value in it, it’s not noticeable…

During our periodic scans we see same and same problems within our clients’ websites. When they say – “who are going to attack our site using this neat little issue”, we usually reply – “Automated scripts”. Hackers can do this manually as well, of course. And they will if your website is on their target. But automated scripts doesn’t even care who are you and what your website is about. All they need is to some nasty links in your pages or simply deface your website.

The video shows what it means to have a Joomla website and don’t update it on time. As you’ll see – to hack a website is as easy as copy-paste the script and point to the target. Hence timely updating the CMS itself AND all the modules, components, plugins is critical. This applies to ANY website – and especially open-source CMSes.

The hacking method used here is very very simple; it’s a matter of just using the public script. By the way, that’s what script kiddies do all the time. The impact, though, could be very large.

So take the updating seriously.

Care When It Is Not Too Late

Almost half of our new clients come to us after they have been hacked. Most of them rebuild the site and want to check website security status or want to find out what was wrong with their website.

This is good thing under current status quo. However much better would be to care about security in advance and therefore possibly prevent bad things happen.

Our advice is simple: please, if you care about your website, don’t wait for to long.

Why Using Joomla Or Drupal Is More Secure Than Any Custom Made Application

Last week I attended a cyber security conference CyCon held in Estonia. There I had a chance to talk to a couple of guys from web development field. The discussion turned to the security of web applications. We discussed what is safer to use – publicly available open source web applications (for example – CMSes) or custom made websites.

The question is trivial. Public web applications have well known vulnerabilities with ready to use exploit kits. And new vulnerabilities pop up all the time. It doesn’t look promising in terms of security. At the same time private applications remain unknown due to the low prevalence (usually it’s only you using that particular app). Since they are not popular, they are not exploited.

However, there are two important aspects to keep in mind. First, what if you are under targeted attack? What if someone is going particularly after you? And second, what if your web app has some stupid security vulnerabilities that could be accidentally found by automatic (or semi-automatic) security scanners utilized by hackers?

In both cases you are basically left alone (unless you have a contract with the company who made the product). If using private web application you might even not know about the vulnerabilities unless (until) bad things happen.

One more point to keep in mind – if someone wants to hack your website – it will be hacked. That applies to the whole IT security in general (websites, networks, servers, etc.). The question is the time and the price.

Your goal is to make it as hard as possible, so that for the attackers it won’t be worthwhile and so they look for another target.

If you use public applications basically your task is to update them on time and also read and apply installation and security guideline principles. The biggest problem with open source web app is not the application itself, but rather its modules, plugins, etc. While main application is frequently updated, its modules might not. And that pose very important security issue. While a hacker has to find only one vulnerability for a successful attack, you as a protector have to find all the vulnerabilities to be safe.

So despite which version of web app you use it is absolutely necessary to do regular website security scanning as it could reveal possible and unknown vulnerabilities. I would say this is particularly important for custom made applications.

Conclusions

Custom made web application could be more secure then e.g. Joomla, but only if much attention is paid to security. By saying much attention I mean that security is in mind in the whole application development life cycle – planning, developing, testing and supporting. That requires great attitude and big investments.

If you don’t have that – stick to open source CMSes (like Joomla or Drupal). They are public and wide spread, but also many developers constantly take care of their security – as new vulnerabilities appear, they get fixed. So you are not left alone.

If you decide to use Joomla, Drupal or others, it’s very IMPORTANT to update them on time and to use all measures possible to harden them appropriately by following their installation and security guides. Also don’t forget to scan website security at regular intervals.