Working with Flight Recorders
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).
Last updated
