Default Banner

Preventing data leaks

27/03/2018
Preventing data leaks

Personal data and credentials can sell for thousands of euros on the black market, so it is inevitable that attackers are always on the lookout for ways to attack online applications and gain access or extract important data stored within.

A software developers’ focus will mainly be to deliver functional and bug-free solutions. However, throughout the whole production lifecycle, it is easy to overlook certain lesser tasks that can help towards hindering attackers from getting access to the application’s data. With GDPR legislation on the horizon, such oversights could also amount to hefty fines, so let’s take a look at some procedural tasks that should be kept in mind.

HTTPS

With the rise of public hotspots, transferring any type of user data in plain text over HTTP is no longer acceptable. Data transfer over HTTP will leave user data exposed and easily readable by anyone sniffing around the connection. Making sure to install an SSL certificate and force requests over HTTPS when deploying an application is a must. This applies to any sort of processes involving client data and not just when logging in.

Password hashing

If an application is storing user’s credentials (e.g. username & password), one should always assume that access to that database is possible. That is why hashing passwords using algorithms such as SHA together with a unique salt per user should be a standard procedure. Hashing is a form of cryptographic security which differs from encryption. Whereas encryption is a two-step process used to first encrypt and then decrypt a message, hashing condenses a message into an irreversible fixed-length value, or hash. In the unlikely event of a breach, password hashing will prevent anyone, who is looking at a database, from seeing the data such as user’s passwords in plain text.

Secure (Public) API

API is the backbone of every mobile application and in some cases even web and desktop applications. While the end-user never gets to see the actual API, it should never be assumed that no one will attempt to access API outside of the application. In short, if one is retrieving user data following a login, it is important to make sure that data cannot be retrieved by any logged in user just by replacing parameters. This is also applicable to web-pages accepting query string parameters or post data.

Logging

In a live environment, it is sometimes required to make use of logging, for example for debugging purposes or as an audit trail. While in the ideal world, this information should be stored in a database, it is also common practice to store these in a text file. If the text file option is used, it is important to ensure that they are not publicly available. One should never assume that exact urls of these files will not be found, as Google will eventually crawl the website where they reside and index them for returning in search engine results.

Stack trace

Exceptions in code occur every now and then, perhaps because of a bug, a data issue or an unforeseen issue. Whatever the reason is, a user should always see a correct message. The point here is beyond user experience, as default server error pages include a stack trace most of the time, which becomes useful information to advanced users with malicious intent in hinting at went wrong within the code and, depending on the server / language, might also show portions of the code. This will give an attacker enough information on what to attack in order to breach/attack an application.

Injection, sanitisation and validations

While this is a well-documented topic on the internet, it is still important to mention it in the context of this article as there are many applications which still fail to sanitise inputs. Be it query strings, text boxes or any other form of input, it is important to ensure checking procedures are in place. E.g. to check for SQL injection as special characters should be encoded. Failing to do so can have adverse effects on an application or could become a vulnerability to breaches.

 

Claude Sammut is a software developer at Deloitte Digital Malta. For more information, please visit www.deloittedigital.com.mt/software-development