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

Servlet Security2 3/26/2003 Table of Contents: Sever-side security issues JAVA Servlet Security  User Authentication  Access Control  Data Integrity  Confidentiality

Servlet Security3 3/26/2003 Server-side Security Issues Interception of Session State Information Forgery of Session State Information Session Timeout Buffer Overflow Data Validation

Servlet Security4 3/26/2003 Server-side Security Issues (cont’) Page Sequencing Information Reporting Browser Residue User Authentication Logging of Sensitive Information

Servlet Security5 3/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 Security6 3/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 Security7 3/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:

Servlet Security8 3/26/2003 Hidden Form Fields 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 Security9 3/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 Security10 3/26/2003 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

Servlet Security11 3/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 , but forge cookie or rewritten URL by using session ID Countermeasure:  Using large and random number as session ID  Session information encrypted on server

Servlet Security12 3/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 min, with 20 min being a common value

Servlet Security13 3/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 Security14 3/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 Security15 3/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 Security16 3/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 Security17 3/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 Security18 3/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 Security19 3/26/2003 Servlet Authentication Servlet authentication Four types of authentication: HTTP basic authentication HTTP digest authentication Form based authentication SSL client authentication

Servlet Security20 3/26/2003 HTTP Basic Authentication Using dialog box Server ask browser for a username and password Two problems Few people like Weak security Base64-encoded

Servlet Security21 3/26/2003

Servlet Security22 3/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 Security23 3/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 Security24 3/26/2003 Log in Username: Password:

Servlet Security25 3/26/2003

Servlet Security26 3/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 Security27 3/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 Security28 3/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 Security29 3/26/2003 admin Area /admin/* administrators

Servlet Security30 3/26/2003 Example defining users, their passwords and roles in Tomcat 3.2:

Servlet Security31 3/26/2003 Programmatic Security Three methods in javax.servlet.HttpServletRequest: String getRemoteUser() Boolean isUserInRole(String role) Princippal getUserPrincipal() For example:

Servlet Security32 3/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 page res.setContentType("text/html"); java.io.PrintWriter out = res.getWriter(); out.println(" "); out.println(" User Example "); out.println(" ");

Servlet Security33 3/26/2003 // 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(" "); out.close(); }

Servlet Security34 3/26/2003 Data Integrity A servlet container issue Configure web server to use SSL for all connections

Servlet Security35 3/26/2003 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 Security36 3/26/2003 References Professional Java Security, Jess Garms, Danial Somerfield, ISBN Java Security Handbook, Jamie Jaworski, Paul J. Perrone, ISBN

Servlet Security37 3/26/2003 Thank You