The HTTP protocol
Almost everything that we've done so far has relied on the HTTP protocol. The HTTP protocol is the protocol that browsers and servers use for communication. It defines eight separate request methods, from which the
POST are most widely used. Each request method has a set of restrictions and suggestions on the content of the message and on how the message should be processed by the server. For example, Java Servlet API (version 2.5) includes the following suggestion for handling the normal GET requests, i.e. the ones that users use for retrieving data.
The GET method should be safe, that is, without any side effects for which users are held responsible. For example, most form queries have no side effects. If a client request is intended to change stored data, the request should use some other HTTP method.
Data is retrieved using the GET method
The GET method is used for retrieving data. When you type in an address to the browser input field and press enter, the browser performs a GET request. No additional parameters are required. In the protocol, assuming that we are using HTTP/1.1, information on the host machine needs to be sent as well — this is needed so that each server can handle multiple domains.
GET /page.html HTTP/1.1 Host: f-secure.com
We have used the
@RequestMapping annotation for handling GET requests that
are sent to the server. Actually, the same annotation can be used for any of
the HTTP request methods; the annotation can be configured using attributes.
For example, the following annotation would capture GET requests to the path
@RequestMapping(value = "/salmiakki", method = RequestMethod.GET).
Data is sent using the POST method
The practical difference between the POST and GET requests is that whilst GET methods may contain information within the path and the request parameters, content can be added to the body of the POST method. The type of the data in the body is sent as a part of a request header, and it can contain images, videos, music etc.
POST /page.html HTTP/1.1 Host: f-secure.com Content-Type: application/x-www-form-urlencoded Content-Length: 10 ...data...
HTTP is stateless
HTTP is a stateless protocol which means that each request that is sent to a server is processed individually, and from the point of view of the server, the requests are not linked with each others. This design decision was made to make it straightforward to retrieve content from multiple servers and to increase the performance of the HTTP protocol (Basic HTTP as defined in 1992). The decision was initially solid as most of the web traffic was related to transmitting static content.
Identifying users is however needed. For example, web shops and other services that identify users require means to maintain knowledge of the user. A classic — but rather poor — way to maintain knowledge of the user was to use parameters in the GET request that could be used to identify the user. This is not recommended however, as these parameters can also be modified or tampered with.
Currently, many web applications include user-specific functionality that expect that the users can be identified. Here, cookies that were introduced in the HTTP/1.1 protocol are handy. When the server adds a cookie to the response that it sends to the user, the browser of the user will always send the cookie back to the user. This way, sessions across multiple requests can be maintained.
During this part of the securing software course, we briefly visited frontend and backend functionality and looked into how databases are used when developing web applications. During the next week we will look deeper into the typical security issues in web applications.
Remember to check your points from the ball on the bottom-right corner of the material!