Shared Responsibility - Stopping threats at the source

Over the past week Denial of Service (DOS) has been dinner table talk in Australia since the catastrophic failure of it's online Census implementation. Everyone from the Prime Minister down has been quick to blame IBM and, quick to accuse the Chinese government for the attack.

After the dust has settled and reality sets in, the true picture appears. No Chinese conspiracy but certainly poor planning. Expecting the entire population of Australia to log in and complete a multi page form on the same night was in reality... dumb.


One thing that surprised me in all the discussions by the experts was the focus on back-end strategy to mitigate attacks. Surely any strategy should start at the root cause, the user interface. A lot can be done at the source using client-side strategies that prevent malicious traffic ever reaching your resources. Presenting a simple login page without additional protection is surely a magnet for malicious attacks.

A magnet for attack

AWS talk a lot about "shared responsibility". This is a fundamental tenet of good application design. We need to take responsibility for what is within our control and, out of the control of AWS. Allowing threats to reach AWS infrastructure is putting all of the responsibility on AWS and taking no responsibility yourself.

When designing a critical application a number of questions can be asked and the solutions designed into the application:

1. Are you a real browser?
2. Are you a real person?
3. Can I identify you?
4. Do you have permission to be here?

Headless Browsers

In general all threats will come from an automated service, not from a person at a desktop browser. Your first line of defence should be to detect headless browsers. Headless browsers run on a server without any GUI and operate using a simulated Document Object Model (DOM). There are a number of differences between headless browsers and normal browsers that can be used for detection and mitigation:

• Plugins: The available plugins for headless browsers will be minimal and the plugins array will probably be empty. Testing for common plugin availability and plugin array length can identify threats instantly.
• HTML5/CSS3: HTML5/CSS3 support is not a priority for a headless browser as it does not have a GUI. Testing for these features can help identify headless browsers.
• Iframes: Embedding forms within iframes can make it more difficult for bots to identify DOM elements.
• Ajax: Presenting a simple login form with input type password makes life easy for bots. Consider using Ajax to reveal the login process with animation step by step. Also consider varying the time randomly between steps.
• CSS id and classes: Dynamically creating forms allows the opportunity to vary the class names and id of the elements on the form. It also allows the position in the DOM to be varied. This will make it difficult for reliable bot scripts to be created as they are based upon CSS selectors.
• Web Security: Headless browsers do not have the same respect for security as conventional browsers due to the limited value of information contained in browser storage. Also web security features are mostly disabled by bot owners. This creates an opportunity to run client-side scripts on the headless browser that can consume it's server resources. Extreme care must be taken with this approach due to the possibility of accidently targeting innocent visitors.

Captcha:

Captcha is the technology users hate but unfortunately we need. Image type Captcha are the most common and generally effective at preventing brute force attacks.

Image Captcha

Despite this, they can be easily overcome through the use of a Captcha solving service. The bot will save an image of the Captcha and forward it to the service for solving. These services use OCR where possible and actual human entry to solve the Captcha. The reason why this is still reasonably effective is due to the expense involved in using a Captcha service. Bots will generally move on to more cost effective targets.

The latest one-click technology by ReCaptcha is by far the best. Unlike image Captcha, this requires actual real clicks before it is accepted. This technology is extremely effective at distinguishing between real clicks and bot clicks. It is also not possible to transfer the Captcha to a solving service as it is not an image and will be disabled when the Captcha url is run on a different machine. This is certainly a powerful weapon to have in your arsenal.

Federated Identity

If your traffic has come this far it is most likely not a bot and has probably got a Facebook account. Federated users identified through Facebook, Google, Amazon etc are issued with temporary credentials and can be used in conjunction with Amazon Cognito to ensure a high degree of authentication has occurred before AWS resources are accessed. More info:

Using AWS Cognito with Node.JS

Using Cognito with PhoneGap/Cordova

AWS IAM

Not much is needed to be said about AWS Identity and Access Management. AWS supply a fantastic service and it is up to us to make full use of it through the use of  least privilege roles for your federated users and ensuring credentials are temporary and safe.

So, next time you are thinking about security, don't forget about security at the source.

In the next post I will discuss using dynamic CSS selectors to stop the bots.