servlet security

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


Server-side Security Issues Interception of Session State Information Forgery of Session State Information Session Timeout Buffer Overflow Data Validation


Server-side Security Issues (cont’)

Page Sequencing

Information Reporting

Browser Residue

User Authentication

Logging of Sensitive Information


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


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.


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


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.


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


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


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


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


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


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


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


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


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


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 Authentication

Servlet authentication Four types of authentication:

HTTP basic authentication HTTP digest authentication Form based authentication SSL client authentication


HTTP Basic Authentication Using dialog box Server ask browser for a username and password Two problems

Few people like Weak securityBase64-encoded


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


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


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


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


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


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:


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


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>


Programmatic Security

Three methods in javax.servlet.HttpServletRequest: String getRemoteUser() Boolean isUserInRole(String role) Princippal getUserPrincipal()

For example:


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


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

}}


Data Integrity

Data Integrity A servlet container issue Configure web server to use SSL for all connections


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


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


Thank You

servlet security

Documents

session id information

session idsession information

session maintenance

cookie information

extra information

rewritten url

extra path information

web server