Showing posts with label IAM. Show all posts
Showing posts with label IAM. Show all posts

Shared Responsibility 2 - Using Dynamic CSS Selectors to stop the bots.


In my last post I talked about techniques to stop malicious web automation services at the source before they reach AWS infrastructure. Now we will get our hands dirty with some code to put it into action. Don't worry if you are not an experienced coder, you should still be able to follow along.

How do Bot scripts work?

A rendered web page contains a Document Object Model (DOM). The DOM defines all the elements on the page such as forms and input fields. Bots mimic a real user that enters information in fields, clicks on buttons etc. To do this the bot needs to identify the relevant elements in the DOM. DOM elements are identified using CSS selectors. Bot scripts consist of a series of steps that detail CSS selectors and what action to perform on them.

The DOM structure and elements of a page can be quickly identified using a browser. Pressing F12 in your browser will launch developer tools with this information:


To see specific details of a DOM element simply right click on the element on the page and select 'inspect':


This will open up the developer tools with the element identified. You can get the CSS selector for the element easily by again right clicking on the element in the developer tools:



Note that this will be only one representation of the element as a CSS selector (generally the shortest one). There are a number of ways an element can be defined as a CSS selector including:

  • id name
  • input name
  • class names
  • DOM traversal e.g. defining its chain of parent elements in the DOM
  • Text inside the element using Jquery ':contains'.

Dynamic CSS Selectors

To make life difficult to develop bot scripts you can use dynamic CSS selectors. Instead of creating the same CSS selectors each time your page is rendered, you can look at changing these randomly each time.

When using NodeJS and Express this is quite straightforward as your are already rendering pages on the server. Simply introduce some code to mix this up a bit.

Let's Start


First of all set up an EC2 instance with NodeJS and Express set up to render pages. If you are unsure you can view the video below:

https://vimeo.com/145017165

To save you typing, the code is available at Gist (also Blogger tends to screw up code when it is published).

Now let's change index.js to create a simple login form.

Point your browser to the public IP address of your instance to check everything is ok. e.g. xxx.xxx.xxx.xxx:8080

Now change the index.js file to include a dynamicCSS function :

app.get('/', function(request, response) {
  response.send(dynamicCSS())
})

function dynamicCSS(){
 x = ''
 x += '
'; x += '

Please Login

; x += ''; x += ''; x += '' x += '
'; return x }


Now do npm start at the command line of your ec2 instance and refresh the browser page. You will now see our very simple login form:


The problem with this form is that it is really easy to identify the dom elements required to login. The id, name, placeholder all refer to username or password.

Now let's change our code and introduce dynamically created CSS selectors.


var loginElements = {
 username: '',
 password: ''
 }

function dynamicCSS(){
 var username = randomString()
 var password = randomString()
 loginElements.username = username
 loginElements.password = password 
 x = ''
 x += '
' x += '

Please Login

' x += '' x += '' x += '' x += '
' return x } function randomString(){ chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz'.split('') chars.sort(function() { return 0.5 - Math.random() }) return chars.splice(0, 8).toString().replace(/,/g, '') }



This now generates a random string for the id and name tags of the input elements. This makes it not possible to use these in a reliable bot script. If you do npm start again and view the the view the element in developer tools you can see the random strings.

We now need to look at the other ways our elements can be identified as CSS selectors. As you can see the text "username" and "password" is still used in the placeholders and input type tag. Also the DOM structure itself doesn't change dynamically, making it possible to reference the element through traversing the DOM structure.

We will address both problems by creating random decoy input elements with the same parameters. The CSS position property will allow us to stack them on top of each other so that the decoy elements are not visible on the page:

app.get('/', function(request, response) {
  response.send(dynamicCSS())
})

var loginElements = {
  username: '',
  password: ''
}

function dynamicCSS(){
  var username, password
  x = ''
  x += '
' x += '

Please Login

' y = Math.floor((Math.random()*5)) + 2 for (var a=0; a' x += '' loginElements.username = username loginElements.password = password } x += '' x += '
' return x } function randonString(){ chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz'.split('') chars.sort(function() { return 0.5 - Math.random() }) return chars.splice(0, 8).toString().replace(/,/g, '') }


Now when you view the DOM in your browser developer tools,  you can see the decoy input elements created underneath the real input element. If you refresh your browser you will see a different number of elements created each time (between 1 and 5 created).



The bot creator can no longer use the username and password placeholders or input types to identify the elements. They can also not use the DOM structure to traverse through the DOM as this is changing also. As pointed out by a reader of this post (thanks Vadim!), you should also put some random inputs after to handle jquery ":last". A good place would be underneath your logo.
y = Math.floor((Math.random()*5)) + 2
for (var a=0; a'
  x += ''
  loginElements.username = username
  loginElements.password = password
}
for (var a=0; a'
  x += ''
  document.getElementById(username).style.visibility = "hidden";
  document.getElementById(password).style.visibility = "hidden";
}

The next thing a bot script can do is click on an x-y position on the screen. We can handle this by randomly changing the position of the elements.

var loginElements = {
 username: '',
 password: ''
 }

function dynamicCSS(){
  var username, password
  x = ''
  if ((Math.random()*2) > 1)
    x += ''
  else
    x += ''
  x += '
' x += '

Please Login

' y = Math.floor((Math.random()*5)) + 2 for (var a=0; a' x += '' loginElements.username = username loginElements.password = password } x += '' x += '
' return x } function randomString(){ chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz'.split('') chars.sort(function() { return 0.5 - Math.random() }) return chars.splice(0, 8).toString().replace(/,/g, '') }


The position of the input elements is now random. This currently only has two positions but you can elaborate on this to create many possible combinations of positions. You may also make your login form inside a modal window that changes position on the screen.

If want to go further you can look having two login forms, username followed by password. Or even better, randomly change between the two.

We have now addressed the possible techniques a bot creator can use to identify your input elements and login to your site.

Congratulations, you made it to the end!

What's next?

In my next post I will introduce techniques to identify bots and then look at launching a counter attack on the bot to crash it after it has been positively identified.

Be sure to subscribe to the blog so that you can get the latest updates.

For more AWS training and tutorials check out backspace.academy

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.



New Video lab - Using AWS Identity and Access Management (IAM)

We have added a new lab video to the Amazon IAM subject of the AWS Certified Solutions Architect Associate course.

Using AWS Identity and Access Management (IAM)
  • Creating users and groups 
  • Creating IAM roles.
  • Creating an account password policy.
  • Downloading a credentials report.