Instart Script Control Test Drive Guide

Overview

Third-party JavaScript, once loaded in the browser, can access any element in the user's session. This means that scripts outside of your direct control can potentially access anything the user types into a form – including credit card numbers and personal information – and any cookies that are present in the session.

Imagine that one of these third-party scripts that you are implicitly trusting has been compromised, and now it's running in your users' browsers. It's logging keystrokes and exfiltrating the data users are typing into forms.

This is exactly what happened to British Airways last September in a well-publicized data breach that skimmed 380,000 payment cards.

Welcome to the Test Drive for Instart Script Control, the best way to protect against web skimming attacks on your websites. We have prepared your accounts with a small amount of synthetic traffic and data so you can safely and easily get hands-on experience with our service in the context of your own website. A Test Drive configuration has been set up that mirrors a production configuration, but is only used to enable your testing.

We recommend you take the following three steps:

Step 1: Explore Script Control Analytics: Log in to the account we've set up for you. Explore the analytics available within our offering that show you the frequency of read and write requests from various scripts. With our offering you can see a time series analysis with filters that help you see how your site info is being accessed by the scripts on our site. We encourage you to try different filters to drill in and see the true power of our analytics.

Step 2: Evaluate form field protection: Evaluate form field protection by actually observing third-party code logging keystrokes in some form fields – and also being prevented from doing so by our form protection rule – using a sandboxed Chrome browser extension. This will give you a clear demonstration of possible threats that might exist on your website and how our service can protect against them.

Note: In no way does the Instart Script Control Test Drive affect your website or use any real data from your actual users during steps 1 and 2.

Step 3: Trial with real data: Trial Instart Script Control on your site with real traffic by easily adding a tag to your page.

Your Test Drive account has been pre-configured with some form field and cookie access rules. Most of the rules are configured in Monitor mode, which provides intelligence on which scripts are accessing your form fields and cookies. With the tag installed on your site, you will be able to see the actual behavior of your tags in production in the Analytics screen. You will have the ability to change any of these rules from Monitor to Deny mode to prevent access for any of your form fields or cookies.

Step 1: Explore Script Control Analytics

About your trial account

To show you the power of Instart Script Control, we have set up accounts in our demonstration portal and provided you with a username to log in. We will then provide you with a password in a separate message.

We have prepared your accounts with some synthetic traffic and data so you can safely and easily get hands-on experience with our service in the context of your own website. A Test Drive configuration has been set up that mirrors a production configuration, but is only used to enable your testing.

Your Test Drive account has been pre-configured with some form field and cookie access rules. Most of the rules are configured in Monitor mode, which provides intelligence on which scripts are accessing your form fields and cookies. With the synthetic data that your account has, you will be able to see this information in the Analytics screen. You will have the ability to change any of these rules from Monitor to Deny mode to prevent access for any of your form fields or cookies.

Step 1: Explore Script Control Analytics

After logging in with the credentials we provide, you will see the Analytics screen:

The Analytics screen displays information about requests that matched tag control rule conditions and had the rule actions applied.

Filters

At the top is a filters section to allow you to narrow down the results displayed.

By default the Resource and Action filters are set to All.

For Action, you can select

  • All

  • Control cookie access

  • Control form access

You can select how to list the action events by selecting from the Group by pulldown. The choices are:

  • Under App:

    • Page Domain

    • Resource Domain

    • Page Event

  • Under Client:

    • Country

    • Browser

    • Device

You can specify the Time Period for the display. Choices are

  • Last 24 hours

  • Last 3 Days

  • Last 7 Days (the default)

  • Custom

Custom allows you to pick a start and end date from a calendar widget.

You can further narrow down the list of events displayed by applying Additional filters and specifying criteria and values for them. For example, you could filter on Page Domain with Filter Criteria set to equals and Filter Value set to images.acme.net and click Apply, and only those events that were applied to images.acme.net would be displayed.

Graph

Below the filters is a graph showing the number of times rule actions were triggered during the selected time span. When you hover the cursor over the plot, specific information about that point on the graph is displayed:

Aggregated actions list

Beneath the graph is a list of aggregated totals for the rules that were triggered. The left column shows the selection from the Group By filter, and the right column shows the total number of times the rule triggered for that grouping and the selected Action (and Access if applicable.)

For example, if Resource is set to Form, Group By to Script domain, and Action to Monitor Write, the list shows the number of times that scripts attempted to write to form fields that were specified in one or more script control rules:

Step 2: Evaluate form field protection

In order to show you a third-party script trying to exfiltrate data entered into form fields, we have provided a Chrome extension called Instart Test Drive – Form Protection which injects a Magecart-type script, performing a dummy web skimming attack into your browser and displaying your keystrokes.

Note: This script injection occurs only locally in each tester’s browser and so in no way compromises your actual website and production traffic.

Download and install the Instart Test Drive – Form Protection Chrome extension from here, then perform the following steps to see the extension in action:

  1. The extension has two controls: Insert Form Protection enables the Instart client code, and Insert Malicious Script. Enable both.

  2. Navigate to the page on your site that has the form to test.

  3. Type some text in the form fields. The test rule that we've configured has some of these fields protected in Deny mode. Observe the extension logging your keystrokes in the unprotected fields, and notice that it cannot do this in the protected fields.

Similar attacks can take place in your website if any of the scripts on your page were compromised, including the ones coming from third parties. By putting the access control rules in Deny mode you get full protection from such attacks.

Step 3: Trial with real data

Now that you've seen how third-party code in the browser can access what a user enters into a form, we can show you how Instart Script Control can protect against this for real world traffic.

To do so, all you need to do is add the following JavaScript code to one or more test pages (ones that contain a form) on your site:

<script type="text/javascript" onload="this.parentNode&&this.parentNode.removeChild(this)" data-config='{"SyncConfig": true, "Customer": "instartdemo" }' src="https://www.nanovisor.io/i10c@p1/nanovisor/latest/auto/instart.js?i10c.opts=tac&i10c.nv.host="www.instartdemo.com"></script>

where you would replace the value of Customer in the JSON object with your customer name and the value of the i10c.nv.host query string parameter with the domain you are using to test (both indicated in bold above).

On the form on the test page, identify the DOM selector(s) for one or more of the form's fields. You use this information when you create a form field protection rule to prevent the third-party code from being able to access the values entered in these fields.

(For details on how to determine DOM selectors for form fields, see below.)

After saving the rule, it takes about 10-15 minutes to be validated and deployed across our global network. One way to determine that the rule is working is to run the Test Drive extension again and enter some text in one of the fields. You should now see the extension can no longer access this data.

You will also be able to see events in the Analytics screen after about 5-10 minutes have passed for any scripts that might trigger the rule.

Creating form field protection rules

A form field protection rule allows you to protect form fields from access by specific scripts.

To create a form field protection rule:

  1. Click on Script Control > Rules to display the Script Control Rules screen

  2. From the Rules page, click Add a new rule to open the rule builder.

  3. Enter a description (required) and one or more optional labels if desired.

  4. Click the pulldown labeled Select a rule type and choose Form protection rule. This opens up an Identify App block and a Protect Form Field sub-rule block:

The match specification in the Identify App block is set to Use criteria, match conditions by default, and a Select Criteria field is shown.

You could also set the match specification to No criteria – always match, which means the rule will be applied to any request; in this case the criteria selector below it disappears. If you are specifying criteria to match, the pulldown provides the following choices:

  1. In the Protect Form Field block, specify the Resource URL pattern, the Element selector, and choose to deny read access, write access, or both:

The URL pattern specifies the script or scripts you want to prevent from being able to read and/or write the value of this form field. The match condition can be matches any of or does not match any of, and therefore specifies a regular expression.

The Element selector is the DOM selector that specifies which form field you want to protect. This is typically the ID attribute of the element, but any valid selector that specifies the element will work. See below for how to best determine the selector for the field of interest.

For the Element selector, the match conditions can be equals any of or does not equal any of, and therefore specify an exact match for the value or values you enter.

For this example, the following rule specification will allow only the script processtransaction to read or write the value of the form element with an ID of ccnum:

  1. You can enter additional form field protection rules for other form fields by clicking the Create a sub-rule pulldown and selecting Protect Form Field to add an additional block:

  1. When you have finished defining your rule, click Save at the bottom of the rule. A Change Reason box appears. Fill in a note about why you are creating this rule and click Submit. The rule is saved and will appear in the list of rules on the Script Control Rules screen.

Determining a form field's selector

You can use your browser's developer tools to find the DOM selector that specifies which form field you want to protect. For example, in Chrome, right-click on the field of interest and select Inspect to quickly open the Developer Tools console with the element selected:

Then, right click on the element and select Copy > Copy selector from the popup menu:

Copy the element selector to the clipboard.

Caution

Note that if your selector is not specific enough, this will cause the Nanovisor to examine all elements that match the selector, which can affect performance. The id attribute is ideal because it is unique.