Flight Recorder data can also be graph indexed. For example, you may wish to record the country of origin of any given attack, making it possible for you to create a chart showing the high-risk countries for your application.

To chart the entries for a given Flight Recorder, click on the column to graph in the Flight Recorder search result. In our example, the two browsers used have been graphed as shown:

We may now wish to investigate this further. To do this we can download the events recorded by the Flight Recorder as test data. Simply click on the number in the Records column to be presented with a page identical to the one used to download test data from an active server:

Simply nominate a repository and file name to place the test data in and click on Retrieve.

Once the test data has been retrieved, you can view it by selecting it in the administration tree.

Flight recorders are essentially on-demand log files. Their most common use is to gather data for later study or forensic requirements.

A good example of the use of a Flight Recorder is the following snippet adapted from a banking demo:

In the above example, all of the data about the particular access to the application has been obtained with the HTTP Request Tracker. The next rule is an Injection Checker rule that will check all submitted fields for Java Script, IFRAMEs, SQL injections etc. Should one be found, a Flight Recorder Trigger is invoked, recording the field in which the attack is found, the contents and the URL of where the attack occurred. This data is keyed by DEVICE_ID in this case. The full properties for the Flight Recorder Trigger are shown below:

When this rule is hit, a number of things happen:

An open record is written to an index table (whose name will start with “ATTACK” and which will be found in the “HISTORY” database. Should the table not exist, it will be created). A record of all the fields presently available for rules is also stored in a data table (using the same creation conditions as the index table).

Up to 5 user-defined index fields are also written to the index table, alongside a number of default data elements, such as the browser type, IP Address and User ID (if known).

So now we have a complete record of what happened at this specific point in time. We then close the rule set by logging the user off (since attempting an attack is a pretty serious violation of terms of use).

However, we may wish to continue recording any further activity performed by this user, since it may yield useful forensic information. So, we also insert a Flight Recorder Add rule.

The index table is keyed by DEVICE_ID, meaning that subsequently, if the same DEVICE_ID is found by a Flight Recorder Add rule, it will add another record of all of the fields presently available to the Flight Recorder’s data table. The properties for the Flight Recorder Add rule are as follows:

This essentially maps the key fields to the trigger.

Now, we not only have the data from the point in time of the attack, but also, we have started a specific log of all subsequent activity coming from that DEVICE_ID.

This data is recorded in the same format as test data and can be downloaded and used in the same way (as a Microsoft Excel compatible spreadsheet or by running rules over it on the test server).

Defining the attributes of the flight recorder in the console is an administrative function and must be performed prior to accessing the flight recorder. However once done, the flight recorder information can be accessed and searched. To do this, simply click on Flight Recorders in the console tree.

You will be presented with the following search screen:

You can select ranges of fields for searching or simply click the Search button to view all Flight Recorders:

In this case there is one Flight Recorder in the ATTACK table in the HISTORY database. You can see the DEVICE_ID used to trigger the attack, when it was started and its status (Open meaning that it is still recording, Closed meaning that recording for the specified DEVICE_ID has been stopped).

Following this is the number of records recorded so far for the given DEVICE_ID, the reason for the trigger, the IP address, the User ID (if known), the Case Number if a case has been triggered and the Browser used at the time of the trigger.

We can deduce that someone attempted an SQL injection attack in the password field on the QwertyLogon page.