3/26/2003 Servlet Security 1
Servlet Security
CSCI 5931.01Research Topics in Computer Science--Web SecurityInstructor: Dr.YangStudents: Shiyou Li, Gang Zheng
Servlet Security 23/26/2003
Table of Contents:
Sever-side security issues JAVA Servlet Security
User AuthenticationAccess ControlData IntegrityConfidentiality
Servlet Security 33/26/2003
Server-side Security Issues Interception of Session State Information Forgery of Session State Information Session Timeout Buffer Overflow Data Validation
Servlet Security 43/26/2003
Server-side Security Issues (cont’)
Page Sequencing
Information Reporting
Browser Residue
User Authentication
Logging of Sensitive Information
Servlet Security 53/26/2003
Session State Maintenance HTTP is a stateless protocol, every browser request
and server response is independent each other.
Mechanisms for session maintenance:Cookies
URL Rewriting
Hidden Form fields
Servlet Security 63/26/2003
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.
Servlet Security 73/26/2003
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
Servlet Security 83/26/2003
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.
Servlet Security 93/26/2003
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
Servlet Security 103/26/2003
Intercept of session state information (cont’)
Hidden form vulnerability:Sent between browser and serverSince it used with client-side scripts, the
communication is less than cookies or URL rewriting
Countermeasure: SSL encryption between client server
Servlet Security 113/26/2003
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: Using large and random number as session ID Session information encrypted on server
Servlet Security 123/26/2003
Session Timeout Two mechanism to terminate a session
Explicit clicking a link (eg. logout) Set 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 min, with 20 min being a common value
Servlet Security 133/26/2003
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
Servlet Security 143/26/2003
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
Servlet Security 153/26/2003
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
Servlet Security 163/26/2003
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
Servlet Security 173/26/2003
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
Servlet Security 183/26/2003
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
Servlet Security 193/26/2003
Servlet Authentication
Servlet authentication Four types of authentication:
HTTP basic authentication HTTP digest authentication Form based authentication SSL client authentication
Servlet Security 203/26/2003
HTTP Basic Authentication Using dialog box Server ask browser for a username and password Two problems
Few people like Weak securityBase64-encoded
Servlet Security 223/26/2003
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
Servlet Security 233/26/2003
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
Servlet Security 243/26/2003
<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>
Servlet Security 263/26/2003
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
Servlet Security 273/26/2003
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:
Declarative Programmatic
Servlet Security 283/26/2003
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:
Servlet Security 293/26/2003
<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>
Servlet Security 303/26/2003
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>
Servlet Security 313/26/2003
Programmatic Security
Three methods in javax.servlet.HttpServletRequest: String getRemoteUser() Boolean isUserInRole(String role) Princippal getUserPrincipal()
For example:
Servlet Security 323/26/2003
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 pageres.setContentType("text/html");java.io.PrintWriter out = res.getWriter();out.println("<HTML>");out.println("<HEAD><TITLE>User
Example</TITLE></HEAD>");out.println("<BODY>");
Servlet Security 333/26/2003
// Get the username from the request.// This will be nullString 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 pageout.println("</BODY>");out.println("</HTML>");out.close();
}}
Servlet Security 343/26/2003
Data Integrity
Data Integrity A servlet container issue Configure web server to use SSL for all connections
Servlet Security 353/26/2003
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
Servlet Security 363/26/2003
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