Transcript Chapter 12 Web app security

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


Authorization


Give subject access to restricted resources
Confidentiality


Verify the identity of the subject
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


Authenticate client


Find out whether the resource has security
constraints
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 tomcatusers.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/sslhowto.html
