CHAPTER 12 WEB APP SECURITY

THE BAD GUYS ARE EVERYWHERE

As a web application developer you need to protect your web site

There are three main kind of bad guys you need to watch out for: Impersonators Upgraders Eavesdroppers

EXAMPLE IMPERSONATOR

EXAMPLE UPGRADER

EXAMPLE EAVESDROPPER

THE BIG 4 IN SERVLET SECURITY

Servlet security boils down to four main concepts Authentication

Verify the identity of the subject Authorization

Give subject access to restricted resources Confidentiality

Information is not leaked to persons who should not have the access

Data integrity Data is not modified illegitimately

AUTHENTICATION

AUTHORIZATION

CONFIDENTIALITY AND DATA INTEGRITY

HOW TO AUTHENTICATE IN HTTP WORLD (BASIC AUTHENTICATION)

HOW TO AUTHENTICATE IN HTTP WORLD (BASIC AUTHENTICATION)

CONTAINER CAN CONTROL AUTHENTICATION AND AUTHORIZATION

In stead of coding authentication and authorization in servlet and jsp programmatically, container can control authentication and authorization Thus the application developer do not have to

write authentication and authorization logic for each individual serlvet and jsp program

HOW DID THE CONTAINER DO THAT?

Perform a lookup on the resource being requested Find out whether the resource has security

constraints Authenticate client

Find out whether “Bob” really is Bob The Container has to see whether the user,

say Bob, is allowed to access the resource

KEEP SECURITY OUT OF THE CODE

For most web app, most of the time, the web app’s security constraints should be handled declaratively, in the deployment descriptor

Why?

SECURITY REALM

As far as the servlet spec is concerned, a realm is a place where authentication information is stored

When you are testing your application in Tomcat, you can use a file called tomcat-users.xml. This file is the realm. Also called memory realm because Tomcat reads

this file into memory at startup time Disadvantage: You cannot modify the file’s

content without restarting Tomcat

ENABLING AUTHENTICATION

To get authentication working, you need to stick something in the Deployment Descriptor.

To start using http basic authentication

AUTHORIZATION STEP 1: DEFINE ROLES

Define the roles in a vendor-specific file tomcat-users.xml

AUTHORIZATION STEP 1: DEFINE ROLES

Map the roles in the vendor-specific “users” file to roles established in the Deployment Descriptor

AUTHORIZATION STEP 2: DEFINING RESOURCE/HTTP METHOD CONSTRAINTS

This is where we get to specify, declaratively, that a given resource/method combination is accessible only by users in certain roles

THE <SECURITY-CONSTRAINT> RULES FOR <WEB-RESOURCE-COLLECTION> ELEMENTS

The purpose of the <web-resource-collection> sub-element is to tell the container which resources and HTTP method combinations should be constrained in such a way that they can be accessed only by the roles in the corresponding <auth-constraint> tag

USE PROGRAMMATIC SECURITY WITH DECLARATIVE SECURITY FOR FINE-GRAINED SECURITY CONTROL

In stead of authorizing at the HTTP method level (GET, POST, etc.), you can customize a service method to behave based on the user’s role

Suppose we defined the role “Manager” in the DD, the following code customize the response to the Manager

if (request.isUserInRole(“Manager”)){ //show info related to all employees ……} else { //show info only related to a particular employee ……}

FOUR AUTHENTICATION TYPES

BASIC Transmits the login information in an encoded

(not encrypted) form Encoding scheme: base64 Very weak security

DIGEST Authentication transmits the login information in

a more secure way

FOUR AUTHENTICATION TYPES

Client-CERT The client need to have a certificate before they

can login to the system FORM

FORM authentication lets you create your own custom login form out of anything that is legal HTML

Form info is transmitted in the least secure way

FORM-BASED AUTHENTICATION

First, you create your own custom HTML form for the user login

Then you create a custom HTML error page for the Container to use

What you do:

FORM-BASED AUTHENTICATION

FORM-BASED AUTHENTICATION

SECURING DATA IN TRANSIT:HTTPS TO THE RESCUE

We can tell a J2EE container to guarantee data to be transmitted over a protected transport layer connection, i.e, use HTTPS

To do that, we will use <security-constraint> for both confidentiality and integrity by adding an element called <user-data-constraint> in the DD for the application

SECURING DATA IN TRANSIT:HTTPS TO THE RESCUE

Tomcat supports HTTPS out of the box It won’t necessarily have HTTPS configured

for your application automatically You still need to generate or apply for a

certificate and then configure tomcat to use HTTPS

You may refer to

http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html