Download Web Application Security

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
Web Application Security
2
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
3
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
4
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).
Web Application Security
5
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
6
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
7
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 server’s 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
9
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 CA’s root certificate and Apache Tomcat’s SSL
certificate to Apache Tomcat’s 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 user’s 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