CS4273: Distributed System Technologies and Programming I

Lecture 10: Web Security Programming

Web Application Security

Outlines
Major security issues (Authentication and SSL)
Types of security programming
Declarative and program security

Declarative security
Using BASIC authentication
Using Form-based authentication

Combined declarative and program security

Pure program security

Web Application Security

Major security issues

Prevent unauthorized users from accessing sensitive data
Authentication: identifying users to determine if they are one of the
authorized ones
Access control: identifying which resources need protection and who
should have access to them

Prevent attackers from stealing data from network during

transmission
Encryption (usually by Secure Sockets Layer)

Web Application Security

Authentication
Collect user ID information from end users (logging in)
usually by means of browser dialog / interface
user ID information normally refers to username and password

Transport collected user ID information to the web server

unsecurely (HTTP) or securely (HTTPS = HTTP over SSL)

Verify ID and passwd with backend Realms (security database)

Realms maintain username, password, roles, etc., and can be organized by
means of LDAP, RDBMS, Flat-file, etc.
Validation: the web server checks if the collected user ID & passwd match
with these in the realms.

Keep track of previously authenticated users for further HTTP

operations
Web Application Security

What is Secure Sockets Layer (SSL)?

A protocol developed in 1996 by Netscape for securely
transmitting private web documents over the Internet.
It employs private and public key to encrypt data thats
transmitted over the SSL connection.
By convention, URLs that require SSL connection start with
https: (port 443) instead of http: (port 80).

Web Application Security

Why use SSL?

SSL is necessary if
There is a login or sign in (to protect user name and passwd)
It transmits sensitive data online, such as credit card information,
HKID #, etc.
You need to comply with privacy and security requirements

Source: www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/index.html
Web Application Security

Use of an SSL Certificate

To enable secured SSL connections, the server needs an SSL
certificate signed by a Certificate Authority (CA).
CA verifies the ID of the certificate owner (e.g., www.hsbc.com.hk)
when an SSL certificate is issued.

Each SSL Certificate contains unique and authenticated

information about the certificate owner, such as ID (in X.500
format), location, public key, and the signature of the CA.
It confirms that you are who you say you are in the Internet.

An SSL certificate enables encryption of sensitive information

during online transactions by means of using hybrid
cryptosystem.
Web Application Security

A Sample Certificate
This is a certificate issued by Ace CA:
Data
Version: v1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Ace Certificate Authority, O=Ace Ltd, C=US
Validity: Not Before: Fri Nov 15 00:24:11 1996
Not After: Sat Nov 15 00:24:11 1997
Subject: CN=Jane Doe, O=Ace Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key: 00:d0:e5:60:7c:82:19:14:cf:38: F7:5b:f7:35:4e:14:41:2b:ec:24:
33:73:be:06:aa:3d:8b:dc:0d:06: 35:10:92:25:da:8c:c3:ba:b3:d7:
lf:1d:5a:50:6f:9a:86:53:15:f2: 53:63:54:40:88:a2:3f:53:11:ec: 68:fa:e1:f2:57
Public Exponent: 65537 (0x10001)
Signature
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
12:f6:55:19:3a:76:d4:56:87:a6: 39:65:f2:66:f7:06:f8:10:de:cd:
1f:2d:89:33:90:3d:a7:e3:ec:27: ac:e1:c0:29:c4:5a:69:17:51:dc:
1e:0c:c6:5f:eb:dc:53:55:77:01: 83:8f:4a:ab:41:46:02:d7:c8:9a: fe:7a:91:5c

How SSL Works?

Good video tute at http://www.viddler.com/explore/sdennis/videos/5/
SSL handshake

Browser connects to SSL port 443 on the web server, and Hello msg
exchange btn browser & server on key-exchange, encrypt alg, etc

Web server sends back its SSL certificate. Web browser decides if it wants
to trust the web servers SSL certificate

Web Browser

Web browser and web server both calculate a session key by agreed
key-generation method
Web browser and web server negotiate an encryption cipher

Web Server

Web browser and web server exchange information encrypted by the

session key and the agreed encryption algorithm

More details at https://ssl.trustwave.com/support/support-how-ssl-works.php

CA Root Certificate
Web browser needs the root certificate of the CA that issued the SSL
certificate to the web-server to verify if the web server is trustable.
If the browser does not have/trust the CA root certificate, most web
browsers will warn you

Web Application Security

10

Steps to Enable SSL in Apache Tomcat

1. Obtain an SSL certificate for Apache Tomcat from a CA.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR227
2. Install CAs root certificate and Apache Tomcats SSL
certificate to Apache Tomcats keystore.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=AR234
3. Set up SSL parameters (port #, count, timeout, etc) by adding
<Connector scheme="https" secure="true">...</Connector>
XML block in conf/server.xml.
https://knowledge.verisign.com/support/ssl-certificatessupport/index?page=content&id=SO5306
Web Application Security

11

Types of Web Application Security

There are two major types of web application security
Declarative security
Program security

Web Application Security

12

Declarative Security
None of the individual servlets or JSP pages needs any security conscious
code. You only need to do some configurations (on file web.xml) and
the security is automatically handled by the system.
To prevent unauthorized access
Use the Web application deployment descriptor (web.xml) to declare that
certain URLs need protection.
The server automatically prompts users for username and password upon
requests for access to restricted resources, performs verification, and
keeps track of users who have previously been authenticated.

To safeguard data transmitted over the network

Use web.xml to configure which URLs should be accessible only with
SSL. If users try to access the protected URLs via regular HTTP, the
server automatically redirects them to the HTTPS (SSL) accordingly.

Web Application Security

13

Program Security
Servlets and JSP pages manage (or partially) their own security. All
security (authentication, access control, etc) is done by user programs.
To prevent unauthorized access
Each servlet or JSP page must either authenticate the user or verify that
the user has been authenticated previously.

To safeguard data transmitted over the network

SSL is a common method to safeguard the data on network. You need to
redirect requests to https URLs explicitly in programs.

Web Application Security

14

Declarative security approaches

There are two general approaches to the declarative security
for the Web application framework:
BASIC Authentication
Form-based Authentication

Web Application Security

15

BASIC Authentication
By using declarative security, all you need
to do is to put the protected data in a
directory and declare the directory as
protected in <url-pattern> in web.xml (for
restricted servlet, also declare it in <urlpattern>)
The server will pop up a standard
authentication window asking for username
& passwd upon users requests to access
restricted resources (specified directory or
files).
Web Application Security

16

Steps for the BASIC Authentication (1)

Step 1. Setup realms (username, password and role)
Create a list of users, associated passwords and roles in file <installdir>/conf/tomcat-users.xml as below:

<?xml version="1.0" encoding="UTF-8"?>

<tomcat-users>
<role rolename="sprole"/>
Two roles defined: sprole and admin
<role rolename="admin"/>
<user username="adminuser" password="adminpwd" roles="sprole,admin"/>
<user username="bigboss" password="bosspwd" roles="sprole,admin"/>
<user username="basicuser" password="basicpwd" roles="sprole"/>
<user username="joedoe" password="joeypwd" roles="sprole"/>
</tomcat-users>

Web Application Security

17

Steps for the BASIC Authentication (2)

Step 2. Specify the use of BASIC authentication
Add <login-config> block in file web.xml with an <authmethod> BASIC and <realm-name> subelements as below:

<web-app >
<security-constraint></security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>BASIC Authentication Example</realm-name>
</login-config>
< /web-app>

Web Application Security

18

Steps for the BASIC Authentication (3)

Step 3. Specify URLs (file paths) that should be passwd protected
Configure two subelemetns under <security-constraint> element in web.xml:
1. web-resource-collection specifies URLs that have access control, and
2. auth-constraint specifies user roles that have the access to the protected URLs.
<web-app >
<security-constraint>
<display-name>Security Checking</display-name>
<web-resource-collection>
<web-resource-name>User Validation</web-resource-name>
<url-pattern>/security/*</url-pattern>
</web-resource-collection>
All resources (because of using /*)
<auth-constraint>
<role-name>sprole</role-name>
under the current web application
</auth-constraint>
can only be accessed by users with
</security-constraint>
role sprole
<login-config></login-config>
< /web-app>
Web Application Security

19

Steps for the BASIC Authentication (4)

Step 4. List all possible roles (categories of users) in the
system (only the roles specified in <auth-constraint>
clause can access the protected resource).

List all possible roles in block <security-role> of <web-app>

<web-app >
<security-constraint></security-constraint>
<security-role>
<role-name>sprole</role-name>
<role-name>admin</role-name>
<role-name>user</role-name>
</security-role>
</web-app>
Web Application Security

20

Steps for the BASIC Authentication (5)

Step 5. Specify the URLs that require SSL. When users access
the specified directory, the server redirects requests to https.
Add <transport-guarantee> block under <user-data-constraint> in
<security-constraint> with value CONFIDENTIAL.

<security-constraint>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

</security-constraint>
Web Application Security

21

Do you like BASIC Authentication?

Is BASIC authentication good enough?

Disadvantages
- No customization is allowed (e.g. no
user defined GUI or login pages)
- Can only get username and
password by default

Web Application Security

22

Form-based Authentication
Web server collects user identification information via a
customized login page, e.g.

Web Application Security

23

Steps for Form-based Authentication (1)

Step 1. Setup realms (username, password and role)
Same as the BASIC authentication

Step 2a. Specify the user of Form-based authentication

In web.xml of your web application
<web-app >
<security-constraint></security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Form-based authentication Example</realm-name>
<form-login-config>
<form-login-page>/html/login.html</form-login-page>
<form-error-page>/html/login-error.html</form-error-page>
</form-login-config>
</login-config>
Specify the location of the login and login< /web-app>
error pages (under /WEB-INF/html directory)
Web Application Security

24

Steps for Form-based Authentication (2)

Step 2b. Create customized login page
Can be HTML or JSP page as below:

HTML form must have ACTION of j_security_check,

METHOD of POST, textfield named j_username, and
password field named j_password as following:
Source code:
<form action="j_security_check" method="POST">
<p>User name: <input type="text" name="j_username" id="j_username" /></p>
<p>Password: <input type="password" name="j_password" id="j_password" /></p>
<p><input type="submit" value="Login" /></p>
</form>
Web Application Security

25

Steps for Form-based Authentication (3)

Step 2c. Create login failure page
Can be HTML or JSP page, simply for login failure messages

Web Application Security

26

Steps for Form-based Authentication

Step 3. Specify URLs (file paths) that should be password
protected
Step 4. List all possible abstract roles that will be granted access
to the resource
Step 5. Specify the URLs that require SSL
All the above 3 steps are the same as the BASIC authentication.

Web Application Security

27

Basic vs. Form-based Authentication

Basic

Form-based

Get username and password by

using browser provided dialog
box

Get username and password by

using a customized login page

Only username and password

can be collected

Customized data can be

collected

HTTP Authentication header is

used to convey username and
password

Form data is used to convey

username and password

Web Application Security

28

Problems with pure declarative security

Access is all-or-nothing
Users can access a resource or be denied access to it.
No options to permit resources to customize their output depending
on the username or role of the client that accesses them (i.e. partial
access to information)

Access based on exact password matches

Controlled by server and is case non-sensitive.

Involves server-specific component

It is not completely portable. Different servers may have different
ways of settings.

All pages use same mechanism

Cannot mix form-based and BASIC in same Web application. (not
flexible)
Web Application Security

29

Combined Declarative with Programming Security

Rely on the web-server for authentication (i.e., usernames,
passwords, and roles)
Use Form-based or BASIC authentication

Access control by programs in the servlets or JSP pages

E.g. you can change the result of a particular page depending on who
accesses it. With pure declarative security, it is all or nothing.

Use the following HttpServletRequest methods

isUserInRole: check if the current user is in a specified role, e.g.,
req.isUserInRole("admin");

getRemoteUser: return the user-name who makes this request, e.g.,

name = req.getRemoteUser();

getUserPrincipal: return a java.security.Principal object containing the

name of authenticated user, e.g., name = req.getUserPrincipal().getName();
Web Application Security

30

Combined Security Method

Follow the steps of setting up authentication (use either
FORM or BASIC method)
Server can track users and pop up dialog box if they are
unauthenticated

Web Application Security

31

Servlet Program in Combined Security

Servlet program segment
Specify the information to be accessed by admin role users only
(NOTE: web.xml specifies access to both sprole or admin)
String name = getRemoteUser();
if (name == null)
out.println(name + " haven't logged in. <br>" );
else out.println("Hello, " + name + "! <br>");

if (request.isUserInRole(admin")) {
out.println("<H3>Administrator</H3>");
out.println("Median pay for corporate administrator:");
out.println("<UL>");
out.println(" <LI><B>2004:</B> $500,000.");
out.println(" <LI><B>2005:</B> $600,000.");

out.println("</UL>");
}
Web Application Security

32

Output of the Servlet Program

Data accessed by ordinary users (sprole and admin) and
by admin user only:

Web Application Security

33

Pure Programming Security

Authentication & access control are all done by programs.
NO need to setup security in conf files, server.xml, tomcatusers.xml, web.xml.
Advantages
Totally portable (No server-specific component)
Permits custom password-matching strategies

Disadvantages
Much harder to write programs and maintain
Every resource has to use programmed access control
You can build reusable infrastructure (e.g., servlets that inherit from
certain class or custom JSP tags), but it is still a lot of work

Web Application Security

34

Steps of Programming Security

Use your own database (or other data structure) to store
usernames and passwords, and use getParameter to
collect username and password from client for matching.
Use sessions to track the users that are already logined to
the system.
Turn on SSL by using https (instead of http) of the
web-server in the HTML form (when specifying URL of
CGI to process the username/passwd form).

Web Application Security

35

Programming Authentication with Session Tracking:

an example
protected void doGet() {
// Get the login name and password
String loginName = request.getParameter("UserName");
String password = request.getParameter("Password");
HttpSession session = request.getSession(true);
String xmlResult = "<ServerResponse>";
if (loginName.equals(password)) {
xmlResult += "<LoginResult>Login Success</LoginResult>";
session.setAttribute("Logined", new Boolean(true));
} else {
xmlResult += "<LoginResult>Login Fail</LoginResult>";
session.setAttribute("Logined", new Boolean(false));
}
xmlResult += "</ServerResponse>";
System.out.println("XML Result for Login Servlet: " + xmlResult);
out.print(xmlResult);
}
Web Application Security

36

Programming Security with SSL

Determining If SSL Is in Use
request.getScheme()
request.isSecure()

//returns https or http

//returns true or false

Redirecting to an SSL weblink

response.sendRedirect(https://www.xyz.com/abc.jsp)

Discovering the key-size (Number of bits in the Key)

request.getAttribute(javax.servlet.request.key_size)

Looking Up the Encryption Algorithm

request.getAttribute(javax.servlet.request.cipher_suite)

Accessing Client X509 Certificates

request.getAttribute(javax.servlet.request.X509Certificate)
Web Application Security

37

Using Programming Security with SSL

If HTTP is in use, redirect the web page
over HTTPS automatically

Print out information by using the

functions described in the previous slide
Web Application Security

38

Summary
Declarative security
Requires security configuration and no programming required.

BASIC authentication
Use standard login dialog box.

Form-based authentication
User customized login page.

Combined security
Use isUserRole or getRemoteUser for access control depending on
who accesses resource
Still rely on server for authentication

Pure program security

User has full control of authentication (passwd match) and access
control
Web Application Security

39