## 5 Attack Example
### Attack Scenario  
In a critical web service with low load, the correct way to handle interaction and data gathering would be through a _double input filtering_ scheme. As the word \"double\" suggests, input filtering happens into two different stages in the system. The first stage operates on the client and is often implemented as obfuscated Javascript libraries, in order to make them harder to manipulate for an attacker, but there are no really effective techniques to protect their integrity. Those libraries thus usually control the compliance of user-provided data to basic format assumptions, mainly for the sake of quickness in reporting possible errors. For example let us assume we need to read an email field is formed as following: \(<\)string\(>@<\)string\(>.<\)com, org, info, gov, edu, it... \(.>\). The client-side stage verifies the congruence of what the user types with such a pattern, so for instance if the user inserts _xxxxxx_ it will be flagged as an incorrect input value without involving server-side processing. The second stage operates on the server side. On Web 1.0 platforms, it performed a wealth of checks that were feasible only with the inclusion of server-stored information. Today, most of its work would be repeating the checks already performed by the first stage, with the addition of some binary correctness checks regarding, for example: encoding, boundaries, signedness, _etc_. Since double input filtering results too resource-consuming for an high-traffic participation platform, an overly enthusiastic Web 2.0 approach suggests to simply eliminate the second stage, strengthening the client-side checking procedures, to distribute the computation among end-users. In the end, this creates a commonplace scenario, in which the sacrificed redundancy paves the way for attacks. Let us assume the WP is structured as a central service, as many current services, to delivery short messages, images and multimedia contents among subscribers in the following way:  
* A user writes messages and his followers read the message. * WP uses client input filter libraries written in a client side language such as Ajax of Flash. * WP trusts the input since it has already been checked and filtered from client input filter libraries. The attack on this kind of system works as follows, as illustrated in Figure 3.  
Step (1) represents the classic request phase from user's client to service's server. Step (2) describes the server's response within the embedded input filtering procedure. Step (3) is the core of the attack. The attacker, manipulates the local input control by corrupting local memory or even simply by forging a local HTML page with absolute and remote URIs but without control procedures. The corrupted client interface sends back to the server the attack vector. Step (4) Since the server does not perform double input control, it trusts the stream coming from the client and records it in its database. Step (5) By querying the service, unaware users receive in their web browser the attack vector forged by the attacker. The attack vector is a now a legitimate browser-based application. The decision maker cannot tell the altered application from the correct version, and thus bases the process on inputs that the attacker can arbitrarily set. In terms of the illustrated decision making process, the attacker can operate on the \(IS\) by injecting new contributions which appear to come from a variety of legitimate users, as well as preventing the propagation of legitimate contributions. By doing the latter operation in a targeted fashion (for example by preventing the decision maker alone from seeing some specific pieces of information) the attacker keeps specific control over the perceived \(IS\). By doing the same in a more manifest way (for example by simulating frequent failures during the comment publication attempts) the attacker can disenfranchise participants and lead them to abandon the process altogether.