CS4273: Distributed System Technologies and Programming I Lecture 10: Web Security Programming Web Application Security1

CS4273: Distributed System Technologies and Programming I

Lecture 10: Web Security Programming

Web Application Security 1

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


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)


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


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 that’s transmitted over the SSL connection.

• By convention, URLs that require SSL connection start with https: (port 443) instead of http: (port 80).


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

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

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.


A Sample Certificate

This is a certificate issued by Ace CA:DataVersion: v1 (0x0)Serial Number: 1 (0x1)Signature Algorithm: PKCS #1 MD5 With RSA EncryptionIssuer: OU=Ace Certificate Authority, O=Ace Ltd, C=USValidity: Not Before: Fri Nov 15 00:24:11 1996 Not After: Sat Nov 15 00:24:11 1997Subject: CN=Jane Doe, O=Ace Industry, C=USSubject Public Key Info:Algorithm: PKCS #1 RSA EncryptionPublic 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 EncryptionSignature: 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?

9

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

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

Web BrowserWeb Server

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

Web browser and web server both calculate a session key by agreed key-generation method

SSL handshake

Web browser and web server negotiate an encryption cipher

Web browser and web server exchange information encrypted by the session key and the agreed encryption algorithm

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

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 …


Steps to Enable SSL in Apache Tomcat

1. Obtain an SSL certificate for Apache Tomcat from a CA.https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR227

2. Install CA’s root certificate and Apache Tomcat’s SSL certificate to Apache Tomcat’s keystore.https://knowledge.verisign.com/support/ssl-certificates-support/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-certificates-support/index?page=content&id=SO5306


Types of Web Application Security

• There are two major types of web application security

– Declarative security

– Program security


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.


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.


Declarative security approaches

There are two general approaches to the declarative security for the Web application framework:

• BASIC Authentication

• Form-based Authentication


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 <url-pattern>)

• The server will pop up a standard authentication window asking for username & passwd upon user’s requests to access restricted resources (specified directory or files).

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 <install-

dir>/conf/tomcat-users.xml as below:


<?xml version="1.0" encoding="UTF-8"?> <tomcat-users> <role rolename="sprole"/> <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>

Two roles defined: sprole and admin


Step 2. Specify the use of BASIC authentication– Add <login-config> block in file web.xml with an <auth-

method> 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>


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> <auth-constraint> <role-name>sprole</role-name> </auth-constraint> </security-constraint> <login-config>…</login-config><… /web-app>

All resources (because of using /*) under the current web application

can only be accessed by users with role sprole


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>


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>

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

Form-based Authentication

Web server collects user identification information via a customized login page, e.g.


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><… /web-app>

Specify the location of the login and login-error pages (under /WEB-INF/html

directory)


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>


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


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.


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


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)


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();


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


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>");}

Output of the Servlet Program

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


Pure Programming Security

• Authentication & access control are all done by programs. NO need to setup security in conf files, server.xml, tomcat-users.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


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).


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); }


Programming Security with SSL

• Determining If SSL Is in Use– request.getScheme() //returns “https” or “http”

– request.isSecure() //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”)


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

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


Documents

CS4273: Distributed System Technologies and Programming I Lecture 10: Web Security Programming Web Application Security1