Transcript Servlet Security CSCI 5931.01 Research Topics in Computer Science --Web Security Instructor: Dr.Yang Students: Shiyou Li, Gang Zheng 3/26/2003 Servlet Security.

Servlet Security
CSCI 5931.01
Research Topics in Computer Science
--Web Security
Instructor: Dr.Yang
Students: Shiyou Li, Gang Zheng
3/26/2003
Servlet Security
1
Table of Contents:

Sever-side security issues

JAVA Servlet Security
 User Authentication
 Access
 Data
Control
Integrity
 Confidentiality
3/26/2003
Servlet Security
2
Server-side Security Issues

Interception of Session State Information

Forgery of Session State Information

Session Timeout

Buffer Overflow

Data Validation
3/26/2003
Servlet Security
3
Server-side Security Issues (cont’)

Page Sequencing

Information Reporting

Browser Residue

User Authentication

Logging of Sensitive Information
3/26/2003
Servlet Security
4
Session State Maintenance

HTTP is a stateless protocol, every browser request
and server response is independent each other.

Mechanisms for session maintenance:
3/26/2003

Cookies

URL Rewriting

Hidden Form fields
Servlet Security
5
Cookies

Enable information to be stored in users’ browser

Consists of information sent by server-side scripts in
name-value pair as result of processing a particular
URL requests

Whenever a cookie-enabled browser requests a URL
from a web server, it first checks cookies.

If there are cookies associated with that URL, it send
the cookie information to server as part of URL
request. It might includes session ID information.
3/26/2003
Servlet Security
6
URL Rewriting

Rewrite the URLs of the links of a web page to contain extra
information in the form of query string or extra path
information.

Example : a user named John Doe log in with session
ID=1234 and enter page1.cgi , page1.cgi contains a link to
page2.cgi

When user click link to page2.cgi, the URL is:
http://sample.com/page2.cgi?fname=John&lname=Doe&sessionid=1234
3/26/2003
Servlet Security
7
Hidden Form Fields

<input type=“HIDDEN” name=“id” value=“1234”>

Typically contained in forms that are placed in a
common frame of a frameset

Accessed using client-side javascript

When javascript executes in one page of an
application, it stored values(session ID) in hidden
form fields.
3/26/2003
Servlet Security
8
Intercept of session state information

Cookies vulnerability:
 sent
back and forth with every request and response
 Can be read from cookie file
 Significant vulnerability in Internet café environment

URL rewriting vulnerability:
 URLs
requested and rewritten are passed back and forth
 If intercepted, they can be used to take over a user’s session
3/26/2003
Servlet Security
9
Intercept of session state
information (cont’)

Hidden form vulnerability:
 Sent
between browser and server
 Since it used with client-side scripts, the
communication is less than cookies or URL rewriting

Countermeasure: SSL encryption between client
server
3/26/2003
Servlet Security
10
Forgery of Session State
Information

In some cases, an attacker may be able to take over a
user’s session without intercepting the
communication between browsers and servers


Example: a user log into server with session ID 123456, but forge
cookie or rewritten URL by using session ID 123455
Countermeasure:


3/26/2003
Using large and random number as session ID
Session information encrypted on server
Servlet Security
11
Session Timeout

Two mechanism to terminate a session
 Explicit clicking a
 Set
link (eg. logout)
timeout for session

Implementation: track the last time a user makes a
request to the server

Setting the duration of a session timeout involves
tough tradeoff
 Typically 10-45
3/26/2003
min, with 20 min being a common value
Servlet Security
12
Buffer Overflow




Occurs when amount of input data are larger than the
input buffer
When a buffer overflows, overflow data may
overwrite program data or even instructions or stack
information
Lead to takeover of web server by attacker
Countermeasure: validate the data received from
browser
3/26/2003
Servlet Security
13
Data Validation

Input script tag(<>) and a script in the input field to
execute the script on server

Rewrite URLs or modify hidden form fields to
contains unexpected values (remember /../..?)

Enter numeric values that result in numeric overflow

Cause null value operation in server

Countermeasure: careful server-side validation
3/26/2003
Servlet Security
14
Page Sequencing

Erroneous assumption: user will proceed through the
pages of application in the designed sequence.
 Example:
the first page of a web application is user login,
but will the user really enter the first page?
 What
will happen to the application if the user skip the first
page and type in the URLs of the next page directly?

Countermeasure: code logic to verify that the user
really goes through the login page
3/26/2003
Servlet Security
15
Browser residue

Information related to the user’s interaction with a
web application is stored in the browser’s cache.
 URLs
visited recently
 Web application’s cookies
 Other private user data


What if someone else also have access to the same
computer?
Possible countermeasure: clear the internet temp files,
history files as well as cookies periodically
3/26/2003
Servlet Security
16
User Authentication

One of the weakest while widely used form of
authentication is reusable passwords

 Susceptible to
interception
 Susceptible to
guessing
Countermeasure: account lock-out when a user fail to
login after a specified number of attempts

Problem: susceptible to denial of service attack
3/26/2003
Servlet Security
17
Logging of sensitive information

Web server typically provide the capability to log all
URLs requested by the browsers

Logging data is sensitive because sensitive user
information can be encoded in URLs

Online access to log data should be prohibited.

Log data should not be sent without being encrypted
3/26/2003
Servlet Security
18
Servlet Authentication


Servlet authentication
Four types of authentication:
HTTP basic authentication
 HTTP digest authentication
 Form based authentication
 SSL client authentication

3/26/2003
Servlet Security
19
HTTP Basic Authentication



Using dialog box
Server ask browser for a username and password
Two problems

Few people like
Weak security
Base64-encoded

3/26/2003
Servlet Security
20
3/26/2003
Servlet Security
21
HTTP Digest Authentication


Using message digest to exchange information
How the protocol works







Server creates a nonce
Sends that nonce to the client
Client hashes nonce
Sends hash back to server
Server computes its own hash
Server compares the hashes
Not all browsers and servers support digest
authentication
3/26/2003
Servlet Security
22
Form Based Authentication
A standard HTML page to be used to request
username and password
 Not as secure as digest authentication
 A cookie is set

3/26/2003
Servlet Security
23
<html>
<head>
<title>Log in</title>
</head>
<body>
<form method=“post” action=“j_security_check”>
Username: <input type=“text” name=“j_username”><br>
Password: <input type=“password” name=“j_password”><br>
<input type=“submit” value=“submit”>
</form>
</body>
</html>
3/26/2003
Servlet Security
24
3/26/2003
Servlet Security
25
HTTPS Client Authentication(SSL)





Strongest form of authentication
Simply HTTP over SSL
Requires client to have a private key and a certificate
To ensure your users has a certificate,need to either send
them to a CA such as Veirsign or become your own CA
so you can issue browser certificate
Adds considerable security
3/26/2003
Servlet Security
26
Access Control



Servlet security model is role-based
To check whether a user has access to given resource,
Server checks whether the user in any of those roles
Two ways to specify the roles:


3/26/2003
Declarative
Programmatic
Servlet Security
27
Declarative Security



In the deployment descriptor specify whether a
resource is protected and what roles can access it
Add security-constraint element to descriptor to
prevent unauthorized users
For example:
3/26/2003
Servlet Security
28
<security-constraint>
<web-resource-collection>
<web-resource-name>admin Area</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<web-resource-collection>
<auth-constraint>
<role-name>administrators</role-name>
<auth-constraint>
</security-constraint>
3/26/2003
Servlet Security
29
Example defining users, their passwords and roles in Tomcat 3.2:
<tomcat-users>
<user name=“user1” password=“password1” roles=“role1,role2”/>
<user name=“user2” password=“password2” roles=“role1”/>
</tomcat-users>
3/26/2003
Servlet Security
30
Programmatic Security

Three methods in javax.servlet.HttpServletRequest:
String getRemoteUser()
 Boolean isUserInRole(String role)
 Princippal getUserPrincipal()


For example:
3/26/2003
Servlet Security
31
import javax.servlet.*;
import javax.servlet.http.*;
/**
*
Simple Servlet Example using the getRemoteUser() method.
*/
public class UserServletExample extends HttpServlet {
public void doGet (HttpServletRequest req, HttpServletResponse res)
throws ServletException, java.io.IOException {
// Start printing out the HTML page
res.setContentType("text/html");
java.io.PrintWriter out = res.getWriter();
out.println("<HTML>");
out.println("<HEAD><TITLE>User
Example</TITLE></HEAD>");
out.println("<BODY>");
3/26/2003
Servlet Security
32
// Get the username from the request.
// This will be null
String username = req.getRemoteUser();
if (username == null) {
// User is not logged in.
out.println("Hello. You are not logged in.");
} else if ("Bob".equals(username)) {
out.println("Hello, Bob. Nice to see you again.");
} else {
out.println("Hello, "+username+".");
}
// Finish the HTML page
out.println("</BODY>");
out.println("</HTML>");
out.close();
}
}
3/26/2003
Servlet Security
33
Data Integrity



Data Integrity
A servlet container issue
Configure web server to use SSL for all connections
3/26/2003
Servlet Security
34
Confidentiality




Confidentiality
Encrypting the connection between browser and
server
As with data integrity SSL almost always the way to
go about handling this
The ServletRequest class contains a method
isSecure() determining whether a connection has
taken place over SSL
3/26/2003
Servlet Security
35
References

Professional Java Security, Jess Garms, Danial
Somerfield, ISBN1-861004-25-7

Java Security Handbook, Jamie Jaworski, Paul J.
Perrone, ISBN 0-672-31602-1
3/26/2003
Servlet Security
36
Thank You
3/26/2003
Servlet Security
37