Safeguard your users’ privacy

Ensuring privacy is far from straightforward. Tim Badaczewski
lists some best practices you can adopt to protect your users

Content that must remain private is called ‘Personally identifiable information’ (PII). This is any information that can be used on its own or with other information to identify, contact or locate a person, or to identify an individual in context. The determination of weaknesses comes with some fuzzy logic. We can’t control the security of external networks or the devices users access our apps with, yet we are responsible for any combination of factors that might compromise our apps.

In the last year, government, social and ad-driven websites have all come under the microscope as the perception of what is ‘private enough’ has evolved. Part of that evolution is the natural result of our acceptance of more integrated services in our lives. Users enjoy the convenience of these integrations, but also assume the personal information they reveal won’t be exploited. As app creators we must recognise this and address it.

Picture the scene. Cathy sits in a busy coffee shop browsing the web on the free Wi-Fi as she sips her beverage. One of her friends has just been diagnosed with depression, and she wants to help find a support group. She finds a local group, and uses the site’s contact form to see when they meet. At the same time an attacker is monitoring traffic on the coffee shop’s unsecured network and notices the traffic to the unencrypted domain. They can see the user-agents of the requests and identify Cathy. Viewing the unencrypted traffic, the attacker now knows Cathy’s full name, and the first name of her friend via the contact form she filled out. Cathy’s social network accounts are searchable and after a few minutes of sleuthing, the attacker finds the full name of her friend via an Instagram comment. With the combination of information, the attacker now has enough information to extort her friend.

Looked at individually, the different sources of information might not be considered personal, but the combination is. An application facilitates the context of connected information and must prevent any exploits as a result of those connections.

Get the right certificate

The first and most effective line of defence should be an SSL/TLS certificate. SSL/TLS accounts for less than 1 per cent of the CPU load, less than 10KB of memory per connection and less than 2 per cent of network overhead (istlsfastyet.com). Concerns related to performance are simply a myth.

Unfortunately, all SSL/TLS certificates are not created equal, and you want to pay attention to a few points to make sure you get the right one:

  • Certificate: You want a certificate signed using SHA-2 (support for SHA-1 is slated to end in 2016)
  • Protocol Support: Make sure you support TLS 1.2 (the most recent version of the protocol). Older versions are susceptible to browser exploits such as BEAST and POODLE
  • Key Exchange: The stronger the key used in the session handshake, the less likely it is someone will gain access to the communication channel. You want a key of 2048 bits or more
  • Cipher Strength: You want 256 bit ciphers or above. This is a little tricky because it depends on the ciphers available on your server, and what will
    support your target clients

Perfect forward secrecy

Perfect forward secrecy (PFS) ensures the two keys used for the secure session handshake can’t be compromised. If an attacker can determine the key, they can decrypt your encrypted data. Make sure you have TLS 1.2 enabled on your server, and use a compatible list of ciphers suites. Your cipher suites need to support the clients your app targets. Clients are basically the browser version and operating system versions they run on. Two good resources for generating cipher suites are Apache and Nginx and IIS.

Enforce the https protocol

Just offering a secure connection is not enough, and neither is just using a secure connection for portions of your site. If you have an SSL, institute it site-wide! Enforcing the protocol at the earliest point of communication is best, which usually means a header rewrite performed at the moment the server detects the request.

Apache (via .htaccess)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
IIS (via web.config)
<rule name=”HTTP to HTTPS redirect”
stopProcessing=”true”>
<match url=”(.*)” />
<conditions>
<add input=”{HTTPS}” pattern=”off” ignoreCase=”true” />
</conditions>
<action type=”Redirect” redirectType=”Found” url=”https://
{HTTP_HOST}/{R:1}” />
</rule>

HTTP Strict Transport Security (HSTS) is fairly new, opt-in security feature that enhances the enforcement of the secure protocol by registering
it within the code of the browser itself. Once registered, all future requests will be secure, even before the request to the target application is made.

Apache (via .htaccess)
Header always set Strict-Transport-Security: maxage=
31536000; includeSubDomains; preload
IIS (via web.config)
<httpProtocol>
<customHeaders>
<add name=”Strict-Transport-Security” value=”maxage=
31536000; includeSubDomains; preload “/>
</customHeaders>
</httpProtocol>

Minimise external scripts

External JavaScript references are given kudos for reducing domain requests as well as being more likely to be cached in the user’s browser. The problem with external references is that they are completely out of our control, and we have to take the good with the bad. Before adding an external script reference to an app, ask a few questions:

  • Is there a server-side alternative that would work?
  • Can I host the script within my application?
  • Can this script be referenced via HTTPS?
  • Does a smaller more secure alternative exist that
    fits my needs?

Harden Google Analytics

Finally, since just about everyone uses Google Analytics, hardening the tracking script is a small but important measure. Adding these two lines of code beneath the primary code snippet ensures your users stay anonymous and secure.

ga(‘set’, ‘anonymizeIp’, true);
ga(‘set’, ‘forceSSL’, true);

Final tips

A top tip is to keep any identifiable information out of the URL. It’s true that network sniffers can’t see it when secured, but it’s still visible in web server logs.

GET/POST all variables as part of the encrypted header. If you have an SSL and want a free scan to see if your certificate and server configuration is secured properly, visit ssllabs.com/ssltest.

Tim is a friendly neighbourhood web developer at ICF International. His areas of expertise are responsive design, CSS, JavaScript, C# and security.


This article originally appeared in issue 270 of net magazine.