In recent years, online privacy and security has become an increasingly popular subject of discussion. The recent high profile hacking incidents, technical glitches and customer data leaks (TalkTalk, M&S & British Gas) have increased the need for security.
So how do you build a website which protects customer data and minimises the impact of a security breach?
Risk analysis
At Clevercherry, we begin with a risk analysis. We identify possible attackers and threats to our website, along with the likelihood and the impact of a successful attack.
For example, let’s take a website that runs an open source e-commerce shop. In the event that a highly skilled and organised crime group attacked this website, the impact will be high as they would use many resources to compromise the whole system. On the other hand, the likelihood of this happening is much lower, compared to a sole attacker that uses some already known exploits against the e-commerce installation.
The first step of any Clevercherry web build is to conduct a risk analysis to identify and implement any security measures required. This will identify the most common scenarios and will allow us to prioritise the threats we need to protect against.
Vulnerabilities
One of the most common vulnerabilities we need to protect against is code injection. As a user interacts with a web application, he will be sending data which will be used by the application; a contact form for example. The user fills in his details, these are sent to the web application which saves them in the database.
If the application is not built to handle the user input correctly, a malicious user can craft a special input, which will allow him to manipulate the way the application’s code works. If the user is able to inject some SQL code which will be interpreted by the application (called SQL injection), the attacker will then probably be able to retrieve data from the database which otherwise should be private, or he can increase his access privileges. To protect against these attacks, we constantly do a taint analysis. At any point in the application’s lifecycle, we make sure the variables that store any user input are properly escaped and sanitised, so that no malicious code can be executed.
As proven by the recent high profile data leaks, perfect security is probably impossible to achieve. Regardless of your budget, size, company profile, expertise and techniques, if somebody wants to attack you and spends enough resources, he will probably succeed at one point.
Take the Hacking Team incident, when a highly skilled security consultancy firm was compromised. When we are building our new applications, we try to minimise the impact of a potential successful attack. To make sure the data of our client’s customers is safe, we will always store sensitive information in the database, e.g. passwords, as the results of a one-way hashing function. A hashing function maps arbitrary sized inputs to a fixed length output in an unpredictable way. Whilst it is rather easy to compute the hash of an input, it is difficult to reconstruct the input from the hash (the vast amount of computing power required makes it nearly impossible). We will always store the hash of a password in the database, and when authenticating users we hash their password and compare it to the one we’ve stored. This way, even in the case of a successful data breach, the attacker will not be able to retrieve any user account passwords.
Man in the middle
Attackers can compromise a user’s data without actually attacking the website. Let’s assume Alice is browsing her favourite online shop over Wi-Fi, in her favourite coffee shop. At the same time, our malicious user, Bob, is connected to the same Wi-Fi network. Bob is running a packet sniffer on his laptop, with a network adapter that can run in promiscuous mode (RF monitoring). Bob is receiving all the packets sent by the Wi-Fi router of the coffee shop, therefore conducting an eavesdropping attack.
Bob can now see all the data that Alice sent to the online shop she was browsing, including her authentication details (username and password). Bob can then make a successful ‘man in the middle’ attack by altering the data that Alice is receiving.
To protect customers against this kind of attack, the website should be served only over HTTPS. The HTTPS protocol is using TLS over HTTP. The website has a third party trusted certificate installed, which tells Alice that the website is genuine and all communication between Alice and the website will now be encrypted so that Bob, even if he receives the packets, cannot decrypt them. We are now protecting customers against direct attacks.
Think security!
By building web applications with security in mind and applying best practices, Clevercherry’s approach ensures that the risk is minimised and we can mitigate any attacks, maintaining a low impact. Understanding how vulnerabilities are exploited helps us protect against them and ultimately giving our customers the best possible service.
Return to blog
