AJAX In Action [134]
A classic web application is vulnerable to “screen-scraping” programs that traverse these workflows automatically, crafting HTTP requests that resemble those generated by a user filling in a form. Screen-scrapers can deprive sites of advertising revenue and skew web statistics. More seriously, by automating what is intended to be an interaction between a human and the application, they can subvert the workflow of the application, calling server events out of order, or they can overload server processes by repetitive submission. From a security perspective, they are generally considered problematic.
The data in a classic web application’s pages is often buried within a heap of boilerplate HTML and decorative content. In a well-factored Ajax application, the web pages sent to the client are much simpler, well-structured data. Separation of concerns between presentation and logic is good design, but it also makes the job of a screen-scraper easier, because the data returned from the server is designed to be parsed rather than rendered in a browser. Screen-scraping programs tend to be fragile and are prone to break when the look and feel of the site changes. Visual makeovers of an Ajax client are less likely to alter the signatures of the underlying web services that the client application uses to communicate to the server. To protect the integrity of our application, we need to give some thought to these issues when designing the structure of the high-level API used to communicate between client and server. By API, we don’t mean HTTP or SOAP or XML, but the URLs of the dynamic pages and the parameters that they accept. Example: online battleship game
To illustrate how the design of a web service API affects the security of the application, let’s look at a simplistic example. We’re developing an online version of the classic board game Battleship (see the Resources section), which will be played using an Ajax client that communicates to the server using web services. We want to ensure that the game is cheat-proof, even if a malicious player hacks the client, making it send data to the server out of turn.
The aim of the game is for each player to guess the position of the other’s boats. The game consists of two phases. First, the players each position their pieces on the board. Once this is done, they take turns at guessing particular Licensed to jonathan zheng 270 CHAPTER 7 Security and Ajax Client 1 Server Client 2 Figure 7.9 Data models in an Ajax-based game of Battleship. Once the pieces are positioned, the server will maintain a map of both players’ pieces. The clients will initially model only their own pieces but build up a model of their opponent’s as the game progresses. squares on the board, to see if they can sink the other player’s ships. The master copy of the board is stored on the server during a game, with each client also maintaining a model of its own half of the board and a blank copy of the other player’s board, which gradually gets filled in as their ships are discovered (figure 7.9). Let’s look at the setup stage. First, the board is wiped clean. Then each piece is placed on the board, until all pieces are placed. There are two ways that we can design the service calls that the clients will make to the server during setup. The first is to use a fine-grained approach, with calls to clear the board and to add a given piece at a given position. During the setup phase, the server would be hit several times, once to clear the board and once to position each piece. Table 7.2 describes the fine-grained setup’s API. Licensed to jonathan zheng Policing access to Ajax data streams 271 Table 7.2 Fine-grained web API for Battleship game setup phase URL Arguments Return Data clearBoard.do userid Acknowledgment positionShip.do userid shiplength Acknowledgment or error coordinates (x,y) format orientation (N,S,E or W) The second design is a coarse-grained approach, in which a