1 / 37

Servlet Security

Explore server-side security issues, user authentication, access control, data integrity, and confidentiality in Servlet security. Learn about session state maintenance mechanisms like cookies, URL rewriting, and hidden form fields. Discover vulnerabilities like interception of session state information, forgery of session state information, session timeout, buffer overflow, and data validation. Delve into page sequencing, information reporting, browser residue, and countermeasures for protecting against security risks.

sruth
Download Presentation

Servlet Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related