Summary
eValid activated tests enable comprehensive performance validation of a wide range of web traffic processing devices. Through use of eValid's unique InBrowser™ implementation a manufacturer of a web traffic processing device can be assured that web traffic is processed reliably and accurately.

Background
The web traffic processing device is usually inserted between the user [i.e. the browser] through the web to the web server, as shown in the diagram. Note that the device could be located server side, client side, or both.

Client               <--WEB-->               Server

Client               <--WEB--> [Device] <--> Server

Client <--> [Device] <--WEB-->               Server

Client <--> [Device] <--WEB--> [Device] <--> Server

These devices add features and capabilities such as: general web security, SSL implementations, IPSec, SSL-TLS, SSL-VPN, controlled portals, virus protection, CSG, firewall protection, content analysis engines, intrusion detection, content filtering and protection, SPAM filtering, etc.

Typical available devices process HTML material (web traffic) sent from servers over web into an internal form for local use. A wide range of methods can be used to accomplish desired effects, including encryption, HTML re-writing, etc.

The goal of pre- and post-processing of web traffic processed through the device is to execute filters of specific kinds to achieve the desired special effect(s). Users need to have high confidence that the essential material is never modified in a way that could interfere with correct operation and use of the delivered material. And, they also must have confidence that offending material has been excluded successfully.

In effect, the device and what it does and how it does it have to be invisible. That is, the entire material delivered to the Client by the Server must be unaltered -- it must be the same as if it were delivered direct from the Server. Even the smallest change in the delivered data can potentially be catastrophic.

Experimental Setup
In non-protected operation, information flows from the web to the browser without modification. In protected operation information flows from the web through the device[s] to the browser after being pre-processed and/or post-processed by the device[s]. (Only the dual-device combination is shown for simplification.)

Type        {D = Device; T = Good Data; T'= bad Data}
of
Transaction     	  Explanation 

T  <-----Web-----> T      Non device mode read/write (OK)
T' <-----Web-----> T'     Non device mode read/write (OK)

T  <--D--Web--D--> T      Device transfers good stuff (OK)
T  <--D--Web--D--> T'     Device filters bad stuff (OK)
T' <--D--Web--D--> T'     Device doesn't filter bad stuff (FAIL)
T' <--D--Web--D--> T      Device adds bad stuff (FAIL)

The goal of testing in this structure is to identify instances where the device[s] fail to operate effectively (FAIL), i.e. when T is incorrectly transformed into T' and/or when T' fails to be correctly transformed into T. As the diagram suggests the information transfer and the corresponding expected protections are bi-directional.

Validation Mode
A wide range of eValid Validation Modes is available in eValid to confirm correct processing of web material of all kinds. Properties to pay attention to include:

• Visible text (content viewable by user).
• Page properties.
• Page size, but you would expect size to be modified if additional material is added to URLs for localized processing.
• DOM content, even if index numbers are shifted. The DOM image of a page should be preserved.

  This fact can be validated in a number of ways. See in particular the eValid capability to Vaidate Document Object Properties.

• JScript operation.
• Session cookies.
• Persistent cookies
• Secure session IDs imposed by server

Failure Modes and How To Detect Them
It is often useful to imagine possible failure modes when devising tests to detect such failures. Failure modes include:

• HTML: Material altered, Material dropped, Extra material inserted, Ends of objects incorrect, Extra invisible objects.
• Scripts incorrectly processed (requires dynamic use).
• Images not duplicated, corrupted, invisible properties modified (including possible watermark checking/spoofing).
• Structure of processed page changed because material was added or material was deleted.

Benefits of eValid Solution
The main benefits of using eValid as the testbed for this kind of validation are:

• Automated script playback eliminates human error.
• 100% client side validation.
• Results are highly repeatable.
• Dynamic checking can be validated.
• Site Analysis runs with/without use of device(s): resulting lists need to be the same.

Risks
Additional concerns in applying eValid to web traffic protection device validation include:

• If JScript programs in client are broken or infected they may behave apparently correctly except if the fault is that the modified code contains a trapdoor or trojan horse.
• It is easy to have a false sense of security with visual verification (manual eyeball checking) because it is very easy to make a page look the same, e.g. by use of the "invisible" attribute.
• Use of visible text as a synchronization method is good, but reliance on this as a content verification step is risky.