Chapter 5) Web Application Security

Objective 1) Security mechanisms

5.1) Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.

Authorisation and Authentication

The words used with relationship to security can have similar and apparently overlapping meanings, so it is worth while clarifying the commonly used words. The words authentication and authorization are sometimes used interchangeable but they have different meanings. The term authentication means to authenticate (confirm) that you are who you say who you are. The most common way of doing this in a computer context is the use of a username and password. It is possible to think of other ways, for example via the use of a swipe card or biometric reading such as using a finger print reader, but for the purpose of the exam I will just consider username/password combinations.

Once you have a user authenticated the next step is to decide what resources that user is authorised to use. It is possible to imagine a default authorisation that give access to no resources, thus you have confirmed that you know who the user is and now they cannot do anything. It is more common to give out authorisation according to roles.

Authentication confirms who you are, authorization confirms what resources you can use.

Data integrity

According to the ATIS telecom glossary data integrity is

The condition existing when data is unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed. “
http://www.atis.org/tg2k/_data_integrity.html

By default the HTTP protocol provides no mechanism for ensuring data integrity. An HTTP request responds with a resource and the client assumes that the information received is correct. Over the development of telecommunications several methods have been developed to try to ensure that the information that leaves a server is the same as that received by the client.

For example when the digital/analog modem was the prime way to connect to a remote computer a check digit was used. A mathematical calculation was performed and the result of that calculation was appended to the data that was sent. On receipt the client machine performed the same calculation to ensure that the data had not been modified.

Confidentiality

One definition of confidentiality is

“data or information is not made available or disclosed to unauthorized persons or processes”
http://www.bricker.com/legalservices/practice/hcare/hipaa/164.304.asp

The implication of this is that even if an unauthorized third party gets access to the data it will not have have any meaning to them. The implication of this is that the data will be encrypted, i.e. scrambled in some way that makes it unintelligible to anyone unauthorized.

The main way of ensuring both confidentiality and integrity with Servlets/JSP is through the use of SSL (Secure Sockets Layer) and Client Certificate authentication. In addition to data integrity SSL also provides encryption. The process of doing the calculations necessary for SSL adds an additional burden to the process of serving web resources, so it is generally only used where security and integrity are a high priority. Examples of this are banking systems and the stage of shopping cart processing where the user enters credit card details.

Declarative security

The JSP/Servlet specification supports declarative security via the deployment descriptor (WEB.XML). This means that instead of embedding security details within the body of your servlet or JSP via method calls, it can be defined within the XML tags of the deployment descriptor. The benefit of this is that it needs to only be done once for any number of JSP/Servlets and it is less prone to error, as there is no chance of a programmer forgetting to put in calls to the security system.

The Servlet specification defines several different authentication methods. The method chosen is declared via the auth-method tag within the login-config tag of the deployment descriptor. The following code shows a deployment descriptor defined to use BASIC authentication.

<web-app>
...
  <login-config>
   <auth-method>BASIC</auth-method>
   <realm-name>Basic Authentication Example</realm-name>
  </login-config>
...
</web-app>

Basic authentication is defined by the HTTP 1.1 specification. When a browser attempts to access a protected resource, the server prompts for a username and password. You will recognise this type of security from the generic (ugly) dialog that is produced automatically by the container. This is the same type of security that can be implemented in the Apache web server via the .htaccess file. Although BASIC authentication is easy to implement it offers an absolute minimum of security. The username and password are not encrypted in any way. Note that the contents of the <realm-name> tag will be used by the generic dialog that is produced.


Other sources

Servlet authentication by David Geary
http://www.phptr.com/articles/printerfriendly.asp?p=26265

This objective according to Mikalai Zaikin
http://java.boot.by/wcd-guide/ch05.html#c5s1

Last modified: Sunday, 20 September 2015, 07:21 PM