Web Application Security

Securing web applications in Java involves the very same core security concepts that are known to every InfoSec professional. These concepts and understanding the different authentication mechanisms for the ‘Web component developer’ exam forms the basis of this post. This post assumes knowledge of servlets, deployment descriptors and the servlet life cycle.

The four security mechanisms:

There are four basic security mechanisms that come into play when securing web applications. They are authentication, authorization, confidentiality and data integrity.

Authentication is verifying who you really are. Specifying a name and password is one form of enforcing authentication.

Authorization is giving individuals specific access to resources on given roles. For example, in any banking hierarchy, the manager might be able to access more information than the tellers and other employees.

Confidentiality is making sure that the information that is being transmitted by the sender is received only by the receiver. It should not be viewed by external parties in transit.

On similar lines, Data integrity is making sure that the information that is transmitted is not tampered in any way in transit.

Having seen the four basic security mechanisms, let us see how they are enforced when working with web applications.

Authentication:

a.      ‘BASIC’ authentication:

 The <login-config> method is used to specify authentication in the deployment descriptor or web.xml declaratively using the following way:

<login-config>

        <auth-method> BASIC </auth-method>

    </login-config>

The <auth-method> can take BASIC, DIGEST or CLIENT-CERT as its values. The BASIC form of authentication uses the browser’s pop-up window for entering the username and password.  This is a screen shot of the BASIC form of authentication:

Article37-Part1

 

  The web.xml or deployment descriptor when dealing with ‘BASIC’ form of authentication can be listed as follows:

Article37-Part2

These are some key points regarding the BASIC form of authentication:

  1. It is the least secure form of authenticating a user since the user name and password are both transmitted in an unencrypted way.
  2. The BASIC form of authentication is easy to implement but is browser dependant for providing the ‘username’ and ‘password’ dialog boxes.
  3. There can also be only one <login-config> element in the deployment descriptor.

The servlet for the above web.xml can be appropriately written. The ‘username’ and ‘password’ have to be configured accordingly in the application server. Once the username and password are authenticated, the users based on appropriate roles will be given access to the servlet.

 

b.      The FORM based authentication:

The ‘form’ based authentication is another type of authentication that is again not very secure. This is integrated with the rest of the website.  It can be implemented in the following way in the deployment descriptor:

Article37-Part3

‘login.html’ and ‘error.html’ are two other files that have to be configured when working with FORM based authentication.

The contents of the login.html and error.html are as follows:

Article37-Part4

This will be the output of the web.xml with the appropriate servlet being specified.

Article37-Part5

 

It should be noted that j_security_check, j_username and j_password are all mandatory names that have to be specified when working with FORM based authentication and it is required by the Container.

 Similarly, error.html is specified as follows:

Article37-Part6

 

 

 

 

 

 

If the name and password do not match or if an error arises, the error.html is called. This will be the output of error.html.

Article37-Part7

CLIENT-CERT and DIGEST are other values that can be specified for <auth-method>  

 We will explore more about the other security mechanisms in subsequent posts.

 

About Pavan Gumaste

Pavan Rao is a programmer / Developer by Profession and Cloud Computing Professional by choice with in-depth knowledge in AWS, Azure, Google Cloud Platform. He helps the organisation figure out what to build, ensure successful delivery, and incorporate user learning to improve the strategy and product further.

0 thoughts on “Web Application Security”

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top