1. Slide 1 Web Application Security ©SoftMoore Consulting

2. Web Application Security Two major aspects of web application security 1. Preventing unauthorized users from accessing sensitive data –involves identification of which resources need protection and who should have access to them 2. Preventing attackers from stealing network data while it is in transit – involves the use of Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to encrypt all network traffic between the client and the server (HTTPS) ©SoftMoore ConsultingSlide 2 These two aspects of security are largely independent.

3. Approaches to Web Application Security Declarative security –None of the individual web resources (servlets, JSP pages, HTML pages, etc.) need any security-aware code. –Major security aspects are handled by the server. –Security requirements are specified in web.xml. Programmatic security –The web application manages at least some aspects of security. –To prevent unauthorized access, either a filter or else each web resource must either authenticate the user or verify that the user has been authenticated. –To safeguard network data, either a filter or else each web resource must check the network protocol and manually redirect to HTTPS if necessary. ©SoftMoore ConsultingSlide 3

4. Authentication versus Authorization Authentication – the mechanism whereby systems may securely identify their users. –Who is the user? –Is the user really who he/she represents himself to be? –Authentication is usually achieved by requiring the user to login with a user ID and password Authorization – the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system. –Does this user have access to this web resource? –Authorization is usually specified in terms of roles. ©SoftMoore ConsultingSlide 4

5. Web Application Security Terms A role is an abstract name for the permission to access a particular set of resources in an application. A user is an individual (or application program) that has been defined in the web or application server. A principal (a.k.a. security principal) is essentially the same as a user. A realm is a “database” of users and roles. –can be stored in a file, in a relational database system, or other similar mechanism ©SoftMoore ConsultingSlide 5

6. General Concepts Users are assigned roles. It is possible for a user to have more than one role. A realm maintains the list of users, user passwords, and roles. When a user is authenticated (e.g., when the user logs in), the list of roles associated with that user is determined by querying the realm. Web resources (HTML pages, JSP pages, servlets, etc.) are protected by roles. If a user has the required role, then the user is allowed access to the web resource. Otherwise, access is denied. ©SoftMoore ConsultingSlide 6

7. BASIC versus Form-Based Authentication When a user who has not been authenticated tries to access a protected resource –with BASIC authentication: server sends a 401 status code to the browser browser pops up a dialog box asking for user name and password user name and password are sent in authorization request header –with form-based authentication: server redirects user to a web page with an HTML form for entering username and password In both cases, the username and password are checked against the realm database. If the user has the required role, access is granted. ©SoftMoore ConsultingSlide 7

8. Example Login Using BASIC Authentication ©SoftMoore ConsultingSlide 8 Dialog box from Internet Explorer

9. Example Login Using BASIC Authentication ©SoftMoore ConsultingSlide 9 Dialog box from Firefox

10. Example Login Using Form-Based Authentication ©SoftMoore ConsultingSlide 10

11. Form-Based Authentication 1. Set up usernames, passwords, and roles. –server-specific process –for Tomcat can use file conf/tomcat-users.xml for testing <user username="john" password= "moore" roles="admin,registered-user" /> <user username="jane" password="doe" roles="registered-user" /> ©SoftMoore ConsultingSlide 11

12. Form-Based Authentication (continued) 1. Set up usernames, passwords, and roles. (continued) –can use two database tables realm_user and user_role create table realm_user ( user_id varchar(30) not null, password varchar(40) not null, constraint realm_user_pk primary key (user_id) ); create table user_role ( user_id varchar(30) not null, role varchar(15) not null, constraint user_fk foreign key (user_id) references realm_user(user_id) on delete cascade ); ©SoftMoore ConsultingSlide 12

13. Form-Based Authentication (continued) 2. Define the realm in webapp\META-INF\context.xml <Realm className="org.apache.catalina.realm.JDBCRealm" driverName="org.apache.derby.jdbc.ClientDriver" connectionURL="jdbc:derby://localhost:1527/C:\\DbName" connectionName="jmoore" connectionPassword="password" userTable="realm_user" userNameCol="user_id" userCredCol="password" userRoleTable="user_role" roleNameCol="role" digest="sha" /> ©SoftMoore ConsultingSlide 13

14. Form-Based Authentication (continued) 3. Tell server that you are using form-based authentication (in web.xml).... FORM /login.jsp /login-error.html... ©SoftMoore ConsultingSlide 14

15. Form-Based Authentication (continued) 4. Create a login page (HTML or JSP).... 5. Create an error page for failed login attempts. –no specific content mandated –Sample: “username and password not found” and a link back to the login page –can be either an HTML or JSP ©SoftMoore ConsultingSlide 15

16. Form-Based Authentication (continued) 6. Specify URLs to be password protected.... Sensitive /sensitive/* admin executive... ©SoftMoore ConsultingSlide 16 Multiple web-resource-collection entries are permitted.

17. Form-Based Authentication (continued) 7. List all possible roles that are granted access to any resource. (Required only with servlets 2.4 but not enforced by most servers)... admin executive ©SoftMoore ConsultingSlide 17

18. BASIC Authentication Similar to form-based authentication except –the is BASIC rather than FORM –no need to write or specify the login and error pages Uses a browser-specific dialog to collect the user name and password (not a consistent look-and-feel) No easy way to “logout” short of closing the browser (With form-based authentication, the web application can invalidate the session when the user logs out.) ©SoftMoore ConsultingSlide 18 In practice, most web sites created for external customers use form-based authentication, but many intranet applications use BASIC.

19. Problems with Declarative Security Server-specific –not completely portable Access is all or nothing –can’t customize the result based on the user’s roles Access is based on exact password match –can’t easily customize how user is authenticated ©SoftMoore ConsultingSlide 19

20. Programmatic Security The web application manages at least some aspects of the security. Hybrid approaches are common, where the sever manages some aspects of security and the web application manages other aspects. Examples of hybrid approaches –The server could still authenticate users, but the web application could customize the response based on user roles. –The server could still maintain control over which resources require TLS/SSL/HTTPS. ©SoftMoore ConsultingSlide 20 Declarative security is, by far, the most common approach to web application security.

21. Methods in HttpServletRequest boolean isUserInRole(String role) Returns a boolean indicating whether the authenticated user is included in the specified logical “role”. String getRemoteUser() Returns the login of the user making this request, if the user has been authenticated, or null if the user has not been authenticated. Principal getUserPrincipal() Returns a java.security.Principal object containing the name of the current authenticated user. (The Principal object contains little information beyond the username – primary use is for compatibility with preexisting code not related to servlets or JSP. Most web applications can use getRemoteUser().) ©SoftMoore ConsultingSlide 21

22. Using Filters for Programmatic Security Filters can be used to manage web application security Using filters decouples servlets and JSP pages from the code to manage security, thereby providing some of the benefits of declarative security. Using a hybrid approach, the web application could use declarative security for authentication and programmatic security to manage access control. ©SoftMoore ConsultingSlide 22

23. Example: Restricting User Access public class AccessFilter implements Filter { private static final String HOME_PAGE = "/index.jsp"; private static final String ADMIN_PAGE = "/admin/index.jsp"; private static final String USER_PAGE = "/user/index.jsp";... public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest)request; HttpServletResponse res = (HttpServletResponse)response; String page = HOME_PAGE; // default if user has not // logged in String user = req.getRemoteUser(); ©SoftMoore ConsultingSlide 23

24. Example: Restricting User Access (continued) if (user != null) { if (userInRole("admin") page = ADMIN_PAGE; else page = USER_PAGE; } RequestDispatcher dispatcher = req.getRequestDispatcher(page); dispatcher.forward(request, response); } ©SoftMoore ConsultingSlide 24

25. Modifying web.xml for the Access Filter AccessFilter com.softmoore.security.AccessFilter AccessFilter /admin/* ©SoftMoore ConsultingSlide 25

26. Introduction to TLS and SSL Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are the two primary protocols used by the Internet for secure communication. –TLS is successor to SSL –terms TLS and SSL are often used interchangeably All data sent between the browser and server are encrypted. –URL starts with “https”. –browser usually displays a lock in the lower right corner –based on public-key cryptography and digital certificates ©SoftMoore ConsultingSlide 26

27. Digital Certificates When a browser makes an initial attempt to communicate with a server over a secure connection, the server authenticates itself by providing a digital certificate. Certificates can be signed by a recognized Certification Authority (CA), or it can be self-signed (e.g., for internal use within an organization). Common Certification Authorities –VeriSign (subsidiaries Thawte and Geotrust) –GoDaddy –Comodo ©SoftMoore ConsultingSlide 27

28. Example of a Digital Certificate ©SoftMoore ConsultingSlide 28

29. Specifying Which URLs Require TLS/SSL Within the deployment descriptor:...... CONFIDENTIAL... ©SoftMoore ConsultingSlide 29

30. Additional Requirements for Using TLS/SSL There must be valid keystore and certificate files. –For testing and intranet sites you can create a self-signed certificate using keytool (provided with JDK) –For “real” internet sites, the certificate must be signed by a Certificate Authority (CA) such as Thawte or VeriSign. There must be a Connector element for a TLS/SSL connector in the server deployment descriptor (file server.xml for Tomcat). –By default, Tomcat uses port 8080 for HTTP and 8443 for HTTPS. –The “real” internet uses port 80 for HTTP and 443 for HTTPS. –The location of the keystore file and its password must be specified in the server deployment descriptor. ©SoftMoore ConsultingSlide 30

31. Example: Connector Element in server.xml for Tomcat <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" enableLookups="true" disableUploadTimeout="true" acceptCount="100" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile=".keystore" keystorePass="password" clientAuth="false" sslProtocol="TLS"/> ©SoftMoore ConsultingSlide 31 See “SSL/TLS Configuration HOW-TO” in the Tomcat documentation for additional details.