Website security: what does it mean, and why you shouldn’t underestimate it?

Done! Another great website is ready to be released, and behind the elegance of an intuitive and simple user interface, of an efficient and accurate graphic layout are hidden thousands of HTML lines, blocks of Javascript code with innovative features containing AJAX, jQuery, maybe mixed with a little bit of REST – and again, on the server’s side, other hundreds or thousands of PHP lines, and SQL tables.

Between you, your website and the right compensation which will render feasible the longed for summer vacations, is the client and the approval of the website. The client who maybe is not a complete stranger to IT as he tries to pretend, or maybe it is like that but knows on who to rely on regarding decisions within the sector… the demonstration of the website goes on smoothly, until the fateful question, a variation of any kind on the topic:

“But is the website secure?”

Are you able to give an answer that leaves you calm on the beach, and your client, too being caught up with his new investment?

In this article I will try to provide not only motivated answers, but also make sure that these answers are sincere and satisfy the security requisites of a website. The security issue, in reality, is way ampler, and covers in a uniform manner everything that has to do with our data both in terms of bad-intentioned damages and those caused by software or hardware failure or even catastrophic events, but here we will concentrate above all on the security of the Rich Internet Application and dynamic website (for convenience I will refer to everything simply as ‘website’ – many sites nowadays have complexities even superior to classic RIAs) and how to render more solid the websites based on Javascript, jQuery, JSON, Apache, PHP and SQL. Therefore, about how to make it not only to go on vacation, but also to enjoy them without risking to receive under the sun the classic:

“But there are indecent pictures in home page!”

Basic concepts

First of all, we empty the field of question number 1. Is it possible to have a 100% secure website?

The answer is the first law of security: no, it’s not possible. I can have a 100% secure website now, but later on it won’t be, either because some genius in any corner of the world will discover a new method for breaching the security of the web server, or because a trojan in the client’s structure will open a path through which some hacker will steal, among other files, also the password of the website’s back office which some distracted employee has saved in a text file on the desktop. Or even, simply read on the post-it attached on the keyboard of the same employee. Distracted, or even miscreant: never exclude anything or anyone.

The first concept is clear: the security of your website is a very, very long chain, which contains only in part your work, but also structures and personnel:

the user’s side, that is what the navigator loads: HTML, CSS, Javascript, inside the browser which uses (Firefox, IE, Chrome, etc) and of the operating system (Windows, OS/X, etc);

the internet network, with all the gathering points, the gateways, that is where our HTTP requests travel to;

the web farm, where our website resides physically, all the PHP files, all the databases;

the client’s side: if the application has a back office which allows our client to manage the database, or write the texts, or download images … this also becomes a link of our chain.

Wherever a machine for accessing the network exists, there is the possibility for a technological attack, based on the network security which leaves to be desired, new and old software bugs and never correct (a very common case nowadays, where budget cuts hit with no mercy even the same foundations of any IT department), possible hardware intrusions.

Wherever personnel exists, it doesn’t matter if executives, employees or service staff, you have a potential point of social attack, based on phishing, or through random human relations which allows for the seizure of passwords, at times very classified ones … simply by asking them over the phone. Or after taking a peek behind the photo on the work desk, or under the mouse, or written on the label of the LCD monitor, or easily deducible …

The integrity of the chain is compromised even when only one of its links is compromised. From here we obtain the second law of security:

the security of the entire chain is equal to the security of the weakest link.

Thus: the chain can be attacked in all of its points and in all possible manners, both technological and social, with various degrees of resistance to the attack. Some are absolutely unpredictable and inevitable, or impracticable, which means that a website will never be 100% secure! And as a web developer, there’s not a lot you can do for a good part of these problems.

But this does not mean that you have to stay with your arms crossed: on the contrary! You have three tasks:

create a website which doesn’t lend a hand to technological attacks – we are going to talk about this later on, and in depth even;

involve the client with the problem, make sure they understand s0cial attacks and know how to manage them: if our application generates or makes use of passwords, do not make a compromise on the quality of passwords: ‘equal for all’ passwords are not acceptable (besides, for the protection of privacy discourse, it’s even illegal)! That they are made aware of the risks their data face: it would be like all similar cars had the same key;

prepare the necessary resources and instruments in case the worst would happen: copies of the website in the various versions, backups, configurations, forensic tools and materials – even this is going to be a topic for discussion. And prepare also the explanations to provide the client with, when necessary.

And if you don’t do that? Apart the risk, almost certain, to lose a client maybe even important in case of problems, you might also be sued, you might not be able to show that you did your best – because your website might be used as a Trojan horse to get access to more critical and restricted areas, and all this maybe just for a banal

$h = popen("zip -r 9 $file", "r");

mishandling inside of one of our phps.

How to talk to the client?

It is absolutely necessary to keep a sincere relation with the client since the very beginning, but at the same time provide strong arguments. The idea that a website cannot be 100% secure is scary – but the same thing applies to a store, a vehicle left in a parking lot, an appartment, even more if we are talking about banks, luxury automobiles and villas – in direct proportion. Nobody renounces to buy a car only because there is the risk it might be stolen: in that case, you take care of securing the keys, parking it in a safe place and insuring it!

Same as with the anti-theft device at home which discourages and chases away, but doesn’t provide absolute security, the same way security on the web discourages and chases away – and unlike, alas, with the money stored in the bank, we can eventually make extremely secure backups to allow us, at least, to restore fast what was damaged. On this, the client has to be assured.

In most cases, the client will understand and will be ready to take part in the management of security. In other cases will be less understanding, and the issues he will raise will revolve on these topics:

“It has never happened to me!”

“Nobody knows us – it is an unknown url!”

“There’s nothing of real value on this website!”

“We cannot remember all these weird passwords!”

Topics we have to know how to confront by demonstrating to know the answers:

because it never happened, it doesn’t mean it won’t happen! Whenever the risk is underestimated, that’s when the most damage is caused;

links are spread rapidly, it doesn’t matter who you are: big or small, you are always interesting for the simple fact of having a space on the web which can be used for other scopes. On the contrary: if you are small, you are interesting because you are less ‘powerful’ than the big names, which can afford to unleash armies of lawyers;

the web space, client details, your image and brand are elements of value – you can imagine what an effect it would have if next to your name appeared material, so as to say, at high resolution and colorful in content?

passwords are equivalent to keys – the complexity, as well as the frequency we change them that’s what keeps them secure.

In the next article, we will start to examine the complete structure of a website through all its parts, as if it were a house and we had to value its security observing windows, doors, door locks, walls, letter carriers and meter reading controllers.

But before then, let’s talk …

In your projects, how’s that you have dealt with the security issue in front of your clients? Have you ever had to manage emergency situations?

In that file, stored in plain text, is all the details someone needs to legitimately login using FTP to a website: FTP address, FTP username and FTP password.

Many of the other “free” FTP programs store their details in much the same way. So all a virus has to do is check about 10 different locations in the hard drive and when it finds a file, it reads the contents and then sends the info to a server which then uses that info to infect all the websites it can.

The virus also “sniffs” the FTP traffic and since FTP transmits all data, including username and password, in plain text, it’s easy for it to see and steal the needed information this way as well. I even have a YouTube video showing how easy this is:

So in addition to the helpful guidance you’ve provided here, people may also want to think seriously about moving to SFTP or FTPS and use a program like WS_FTP by Ipswitch, which, while it’s not free, does encrypt the saved passwords.

Just thought I’d add my two cents. Although with inflation, my two cents is probably what you paid for this information – nothing. 😉

Indeed, what you said is just too true. It’s what I call “laziness tax”, I save my password trusting local software (and I trust them for no other reasons than «it’s famous so it must be safe»: truth is, it should be considered “in the hands of the enemy” like all other parts of my web development structure, and a main target just because it’s famous!) because I don’t want to go thru the effort of remembering original passwords.

The scenario you describe, sadly a classic, it’s just like building the strongest keep, tough walls and guards and barbed wire, just to hide the main keys under a brick well visible from distance …

Fact is, while we could, as web developers, follow password safety rules and do it even strictly, we can hardly enforce that on our websites’ users. It doesn’t matter how well we evangelize them: there will be someone storing them in a text file, or in some unsafe password manager, or even infected by a keylogger thus rendering all possible client safety precaution useless.

Hence, when evaluating web security of our websites we should always see any browser request as “suspect”, check it thoroughly – which will be the topic of few following articles – and never ever think we’re 100% safe even after we wrote (supposedly) secure code: always set up an emergency recovery plan, and have forensic tools ready to be able to understand what happened, who caused it and what sort of countermeasures, technical or social, need to be taken to make it less of a threat.

Well stated. I know of many developers that turn to us to help them determine how the site was hacked – mostly to save their reputation.

Often times, it turns out that since the client wanted FTP access, in the unlikely event they ever want to update their own websites, and it turns out to be their PC that had the infection that stole the FTP passwords.

We recommend that if at all possible, create individual FTP accounts for all users. Then be certain that FTP logging is turned on (activated). That way, if a website is hacked, you have verifiable proof of who’s account was used to FTP the infectious files to the website. The only problem with this scenario is when the logs show it’s you.

Quite often, especially on shared hosting accounts, the FTP logging is deactivated by default. So this step has to be performed by someone with Admin access to the website, but it’s usually well worth the trouble.