Definitions of commonly-used terms associated with Contrast technology are as follows:
Contrast is a new security technology for finding vulnerabilities in an application. It finds vulnerabilities by instrumenting the application and virtual machine with sensors and watching the stream of generated events for patterns that represent vulnerabilities. The term Contrast encompasses the entire suite of technologies around this product, including the JVM plugin (the engine), and the Contrast site (the TeamServer).
The Contrast JVM Plugin is a Java agent that is installed in the application server that is hosting the application(s) to be analyzed. This engine generates traces that contain vulnerability results detected by the engine while the application is operating. It periodically sends these traces to its associated TeamServer for further analysis by a human being.
The Contrast site is a web application that receives traces from Contrast engines and allows the analyst to view and triage the results.
When an untrusted data source provides data to the application, a Creation Event (or Source Event) is generated that documents what occurred. This information is stored with the tracked data object that is created and is used to describe where untrusted data came from if a rule generates a trace.
Each event contains the runtime values of the underlying object, the parameters to the method invoked, the return from the method, and the runtime stack trace.
The Contrast engine will detect the same vulnerability conditions over and over in an application, and this would normally cause the same trace to be generated repetitively. To address this, there is duplicate trace elimination logic in both the engine and the TeamServer to eliminate duplicate traces.
An event is generated when the running application calls code that Contrast has instrumented with a sensor.
A policy file contains all the rulepacks to use in the engine along with some configuration information.
In Contrast, propagation happens anytime untrusted data is transferred to another object. When propagation happens in a running program, that generates a propagation event. How propagation is actually modeled in Contrast is defined by the propagation rules within the rules in use by your engine.
A propagation event is generated when a propagation condition is met in a running program as defined by a propagation rule. When the conditions of the rule are met, a propagation event is generated that tracks the tainted data and trace information from the source object to the destination object. The destination object is considered tracked.
To model how propagation actually works in a running application, we write propagation rules. These rules identify the methods that cause propagation and how the propagation passes from one object to another. When we model how a method might cause propagation, we consider the source and the destination. These may be any combination of an object, the parameters to a method, and the result of the method. For example, the
StringBuffer.append() method propagates untrusted data from the first parameter to the object (the
StringBuffer). This is a P2O Propagation in Contrast terms. Similarly, the
toString() method on a tracked object causes the untrusted data to propagate from the object to the method result (the String returned by
toString()). In Contrast this is an O2R Propagation. Again, any combination is possible, including untrusted data propagating from one source to many destinations, or even many destinations to a single source.
A propagator is a method that accepts tainted input and stores or produces tainted output. Propagators and their propagation behavior are identified and defined by propagation rules.
A rule defines a pattern for the engine to look for while monitoring a running application. If the pattern is matched, the engine generates a trace to send to the TeamServer. Each pattern consists of a series of methods ending in a trigger. Each of these methods can also be required. If these methods are detected, the pattern does not match.
A rulepack identifies a collection of rules. A core set of rules are delivered with Contrast, but can be customized and supplemented with custom rules per organization and per application if the customer's license allows.
A method scope can be defined for a rule. When an application's execution leaves the scope defined for a rule, the engine will check the conditions of the rule as defined by its events to determine if a trace should be generated.
A security control is a security mechanism that does something to make input data safe, such as validate input, encode output, check for data level authorization, etc. Security Controls that don't specifically look at data to make a security check, such as validating whether a user is authorized to invoke a particular method, are simply defined as events, which can be monitored by a rule.
A sensor is the instrumentation that Contrast adds to the running application. The sensor's job is to gather data from the immediate method context, generate a simple event, and send it to the Contrast engine.
This is the short name for an untrusted data source.
A trace is a series of events that represent a vulnerability. Traces are generated by the engine anytime that a series of events matches a runtime rule. Traces can be viewed in the TeamServer.
When data flows from an untrusted data source into an object, that object is considered tracked. When data from a tracked object flows into another object through a propagator, then that object is also tracked. Events can be defined in rules that consider whether an object is tracked or not as part of the event definition.
A trigger is part of a rule pattern that indicates that the Contrast engine should go back through the collected events to see if that rule has been matched.
This is a source of dangerous input to the application. It's typically directly from the end user and an HTTP request, but it could be from a back-end partner feed, the application's own database, or any other source considered unsafe.