Client-Side Functionality
In order for the server-side application to receive user input and actions, and present the results of these back to the user, it needs to provide a client-side user interface. Because all web applications are accessed via a web browser, these interfaces all share a common core of technologies. However, these have been built upon in various diverse ways, and the ways in which applications leverage client-side technology has continued to evolve rapidly in recent years.
HTML
The core technology used to build web interfaces is the hypertext markup language (HTML). This is a tag-based language that is used to describe the structure of documents that are rendered within the browser. From its simple beginnings as a means of providing basic formatting to text documents, HTML has developed into a rich and powerful language that can be used to create highly complex and functional user interfaces.
Hyperlinks
A large amount of communication from client to server is driven by the user clicking on hyperlinks. In web applications, hyperlinks frequently contain preset request parameters. These are items of data which are never entered by the user but which are submitted because the server placed them into the target URL of the hyperlink on which the user clicks. For example, a web application might present a series of links to news stories, each having the following form:
<a href=”/news/showStory?newsid=19371130&lang=en”>Sale now on!</a>
When a user clicks on this link, the browser makes the following request:
GET /news/showStory?newsid=19371130&lang=en HTTP/1.1
Host: wahh-app.com
…
The server receives the two parameters in the query string ( newsid and lang ) and uses their values to determine what content should be presented to the user.
Forms
While hyperlink-based navigation is responsible for the majority of client-to-server communications, in most web applications there is a need for more flexible ways of gathering input and receiving actions from users. HTML forms are the usual mechanism for allowing users to enter arbitrary input via their browser. A typical form is as follows:
<form action=”/secure/login.php?app=quotations” method=”post”>
username: <input type=”text” name=”username”><br>
password: <input type=”password” name=”password”>
<input type=”hidden” name=”redir” value=”/secure/home.php”>
<input type=”submit” name=”submit” value=”log in”>
</form>
When the user enters values into the form and clicks the submit button, the browser makes a request like the following:
POST /secure/login.php?app=quotations HTTP/1.1
Host: wahh-app.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 39
Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd
username=daf&password=foo&redir=/secure/home.php&submit=log+in
In this request, there are several points of interest reflecting how different aspects of the request are used to control server-side processing:
■ Because the HTML form tag contained an attribute specifying the POST method, the browser uses this method to submit the form, and places the data from the form into the body of the request message.
■ In addition to the two items of data entered by the user, the form contains a hidden parameter ( redir ) and a submit parameter ( submit ). Both of these are submitted in the request and may be used by the server-side application to control its logic.
■ The target URL for the form submission contains a preset parameter ( app ), as in the hyperlink example shown previously. This parameter may be used to control the server-side processing.
■ The request contains a cookie parameter ( SESS ), which was issued to the browser in an earlier response from the server. This parameter may be used to control the server-side processing.
The previous request contains a header specifying that the type of content in the message body is x-www-form-urlencoded . This means that parameters are represented in the message body as name/value pairs in the same way as they are in the URL query string. The other content type you are likely to encounter when form data is submitted is multipart/form-data . An application can request that browsers use multipart encoding by specifying this in an enctype attribute in the form tag. With this form of encoding, the Content-Type header in the request will also specify a random string that is used as a separator for the parameters contained in the request body. For example, if the form specified multipart encoding, the resulting request would look like the following:
POST /secure/login.php?app=quotations HTTP/1.1
Host: wahh-app.com
Content-Type: multipart/form-data; boundary=————7d71385d0a1a
Content-Length: 369
Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd
————7d71385d0a1a
Content-Disposition: form-data; name=”username”
daf
————7d71385d0a1a
Content-Disposition: form-data; name=”password”
foo
————7d71385d0a1a
Content-Disposition: form-data; name=”redir”
/secure/home.php
————7d71385d0a1a
Content-Disposition: form-data; name=”submit”
log in
————7d71385d0a1a–
JavaScript
Hyperlinks and forms can be used to create a rich user interface capable of easily gathering most kinds of input which web applications require. However, most applications employ a more distributed model, in which the client side is used not simply to submit user data and actions but also to perform actual processing of data. This is done for two primary reasons:
■ It can improve the application’s performance, because certain tasks can be carried out entirely on the client component, without needing to make a round trip of request and response to the server.
■ It can enhance usability, because parts of the user interface can be dynamically updated in response to user actions, without needing to load an entirely new HTML page delivered by the server.
JavaScript is a relatively simple but powerful programming language that can be easily used to extend web interfaces in ways that are not possible using HTML alone. It is commonly used to perform the following tasks:
■ Validating user-entered data before this is submitted to the server, to avoid unnecessary requests if the data contains errors.
■ Dynamically modifying the user interface in response to user actions; for example, to implement drop-down menus and other controls familiar from non-web interfaces.
■ Querying and updating the document object model (DOM) within the browser to control the browser’s behavior.
A significant development in the use of JavaScript has been the appearance of AJAX techniques for creating a smoother user experience which is closer to that provided by traditional desktop applications. AJAX (or Asynchronous JavaScript and XML) involves issuing dynamic HTTP requests from within an HTML page, to exchange data with the server and update the current web page accordingly, without loading a new page altogether. These techniques can provide very rich and satisfying user interfaces. They can also sometimes be used by attackers to powerful effect, and may introduce vulnerabilities of their own if not carefully implemented.
Thick Client Components
Going beyond the capabilities of JavaScript, some web applications employ thicker client technologies that use custom binary code to extend the browser’s built-in capabilities in arbitrary ways. These components may be deployed as bytecode that is executed by a suitable browser plug-in, or may involve installing native executables onto the client computer itself. The thick-client technologies you are likely to encounter when attacking web applications are:
■ Java applets
■ ActiveX controls
■ Shockwave Flash objects
NEXT is ..State and Sessions…….,
