Servlet Security

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

2. Table of Contents: • Sever-side security issues • JAVA Servlet Security • User Authentication • Access Control • Data Integrity • Confidentiality Servlet Security

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

4. Server-side Security Issues (cont’) • Page Sequencing • Information Reporting • Browser Residue • User Authentication • Logging of Sensitive Information Servlet Security

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

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

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

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

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

10. 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 Security

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

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

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

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

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

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

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

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

19. Servlet Authentication • Servlet authentication • Four types of authentication: • HTTP basic authentication • HTTP digest authentication • Form based authentication • SSL client authentication Servlet Security

20. HTTP Basic Authentication • Using dialog box • Server ask browser for a username and password • Two problems • Few people like • Weak security Base64-encoded Servlet Security

21. Servlet Security

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

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

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

25. Servlet Security

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

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

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

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

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

31. Programmatic Security • Three methods in javax.servlet.HttpServletRequest: • String getRemoteUser() • Boolean isUserInRole(String role) • Princippal getUserPrincipal() • For example: Servlet Security

32. 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>"); Servlet Security

33. // 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(); } } Servlet Security

34. Data Integrity • Data Integrity • A servlet container issue • Configure web server to use SSL for all connections Servlet Security

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

36. 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 Servlet Security

37. Thank You Servlet Security