CS4273: Distributed System Technologies and Programming I

1. CS4273: Distributed System Technologies and Programming I Lecture 10: Web Security Programming Web Application Security

2. Outlines • Major security issues (Authentication and SSL) • Types of security programming • Declarative and program security • Declarative security • Using BASIC authentication • Using Form-based authentication • Combined declarative and program security • Pure program security Web Application Security

3. Major security issues • Prevent unauthorized users from accessing sensitive data • Authentication: identifying users to determine if they are one of the authorized ones • Access control: identifying which resources need protection and who should have access to them • Prevent attackers from stealing data from network during transmission • Encryption (usually by Secure Sockets Layer) Web Application Security

4. Authentication • Collect user ID information from end users (“logging in”) • usually by means of browser dialog / interface • user ID information normally refers to username and password • Transport collected user ID information to the web server • unsecurely (HTTP) or securely (HTTPS = HTTP over SSL) • Verify ID and passwd with backend Realms (“security database”) • Realms maintain username, password, roles, etc., and can be organized by means of LDAP, RDBMS, Flat-file, etc. • Validation: the web server checks if the collected user ID & passwd match with these in the realms. • Keep track of previously authenticated users for further HTTP operations Web Application Security

5. What is Secure Sockets Layer (SSL)? • A protocol developed in 1996 by Netscape for securely transmitting private web documents over the Internet. • It employs private and public key to encrypt data that’s transmitted over the SSL connection. • By convention, URLs that require SSL connection start with https: (port 443) instead of http: (port 80). Web Application Security

6. Why use SSL? • SSL is necessary if … • There is a login or sign in (to protect user name and passwd) • It transmits sensitive data online, such as credit card information, HKID #, etc. • You need to comply with privacy and security requirements Web Application Security Source: www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/index.html

7. Use of an SSL Certificate • To enable secured SSL connections, the server needs an SSL certificate signed by a Certificate Authority (CA). • CA verifies the ID of the certificate owner (e.g., www.hsbc.com.hk) when an SSL certificate is issued. • Each SSL Certificate contains unique and authenticated information about the certificate owner, such as ID (in X.500 format), location, public key, and the signature of the CA. • It confirms that you are who you say you are in the Internet. • An SSL certificate enables encryption of sensitive information during online transactions by means of using hybrid cryptosystem. Web Application Security

8. A Sample Certificate This is a certificate issued by Ace CA: Data Version: v1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: OU=Ace Certificate Authority, O=Ace Ltd, C=US Validity: Not Before: Fri Nov 15 00:24:11 1996 Not After: Sat Nov 15 00:24:11 1997 Subject: CN=Jane Doe, O=Ace Industry, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: 00:d0:e5:60:7c:82:19:14:cf:38: F7:5b:f7:35:4e:14:41:2b:ec:24: 33:73:be:06:aa:3d:8b:dc:0d:06: 35:10:92:25:da:8c:c3:ba:b3:d7: lf:1d:5a:50:6f:9a:86:53:15:f2: 53:63:54:40:88:a2:3f:53:11:ec: 68:fa:e1:f2:57 Public Exponent: 65537 (0x10001) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 12:f6:55:19:3a:76:d4:56:87:a6: 39:65:f2:66:f7:06:f8:10:de:cd: 1f:2d:89:33:90:3d:a7:e3:ec:27: ac:e1:c0:29:c4:5a:69:17:51:dc: 1e:0c:c6:5f:eb:dc:53:55:77:01: 83:8f:4a:ab:41:46:02:d7:c8:9a: fe:7a:91:5c

9. How SSL Works? Good video tute at http://www.viddler.com/explore/sdennis/videos/5/ Browser connects to SSL port 443 on the web server, and Hello msg exchange btn browser & server on key-exchange, encrypt alg, etc SSL handshake Web server sends back its SSL certificate. Web browser decides if it wants to trust the web server’s SSL certificate Web browser and web server both calculate a session key by agreed key-generation method Web Browser Web Server Web browser and web server negotiate an encryption cipher Web browser and web server exchange information encrypted by the session key and the agreed encryption algorithm More details at https://ssl.trustwave.com/support/support-how-ssl-works.php

10. CA Root Certificate • Web browser needs the root certificate of the CA that issued the SSL certificate to the web-server to verify if the web server is trustable. • If the browser does not have/trust the CA root certificate, most web browsers will warn you … Web Application Security

11. Steps to Enable SSL in Apache Tomcat • Obtain an SSL certificate for Apache Tomcat from a CA.https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR227 • Install CA’s root certificate and Apache Tomcat’s SSL certificate to Apache Tomcat’s keystore.https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR234 • Set up SSL parameters (port #, count, timeout, etc) by adding <Connector … scheme="https" secure="true">...</Connector> XML block in conf/server.xml.https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=SO5306 Web Application Security

12. Types of Web Application Security • There are two major types of web application security • Declarative security • Program security Web Application Security

13. Declarative Security None of the individual servlets or JSP pages needs any security conscious code. You only need to do some configurations (on file web.xml) and the security is automatically handled by the system. • To prevent unauthorized access • Use the Web application deployment descriptor (web.xml) to declare that certain URLs need protection. • The server automatically prompts users for username and password upon requests for access to restricted resources, performs verification, and keeps track of users who have previously been authenticated. • To safeguard data transmitted over the network • Use web.xml to configure which URLs should be accessible only with SSL. If users try to access the protected URLs via regular HTTP, the server automatically redirects them to the HTTPS (SSL) accordingly. Web Application Security

14. Program Security Servlets and JSP pages manage (or partially) their own security. All security (authentication, access control, etc) is done by user programs. • To prevent unauthorized access • Each servlet or JSP page must either authenticate the user or verify that the user has been authenticated previously. • To safeguard data transmitted over the network • SSL is a common method to safeguard the data on network. You need to redirect requests to https URLs explicitly in programs. Web Application Security

15. Declarative security approaches There are two general approaches to the declarative security for the Web application framework: • BASIC Authentication • Form-based Authentication Web Application Security

16. BASIC Authentication • By using declarative security, all you need to do is to put the protected data in a directory and declare the directory as protected in <url-pattern> in web.xml (for restricted servlet, also declare it in <url-pattern>) • The server will pop up a standard authentication window asking for username & passwd upon user’s requests to access restricted resources (specified directory or files). Web Application Security

17. Steps for the BASIC Authentication (1) Step 1. Setup realms (username, password and role) • Create a list of users, associated passwords and roles in file <install-dir>/conf/tomcat-users.xml as below: <?xml version="1.0" encoding="UTF-8"?> <tomcat-users> <role rolename="sprole"/> <role rolename="admin"/> <user username="adminuser" password="adminpwd" roles="sprole,admin"/> <user username="bigboss" password="bosspwd" roles="sprole,admin"/> <user username="basicuser" password="basicpwd" roles="sprole"/> <user username="joedoe" password="joeypwd" roles="sprole"/> </tomcat-users> Two roles defined: sprole and admin Web Application Security

18. Steps for the BASIC Authentication (2) Step 2. Specify the use of BASIC authentication • Add <login-config> block in file web.xml with an <auth-method> BASIC and <realm-name> subelements as below: <web-app …> <security-constraint>…</security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>BASIC Authentication Example</realm-name> </login-config> <… /web-app> Web Application Security

19. Steps for the BASIC Authentication (3) Step 3. Specify URLs (file paths) that should be passwd protected • Configure two subelemetns under <security-constraint> element in web.xml: • web-resource-collection specifies URLs that have access control, and • auth-constraint specifies user roles that have the access to the protected URLs. <web-app …> <security-constraint> <display-name>Security Checking</display-name> <web-resource-collection> <web-resource-name>User Validation</web-resource-name> <url-pattern>/security/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>sprole</role-name> </auth-constraint> </security-constraint> <login-config>…</login-config> <… /web-app> All resources (because of using /*) under the current web application can only be accessed by users with role sprole Web Application Security

20. Steps for the BASIC Authentication (4) Step 4. List all possible roles (categories of users) in the system (only the roles specified in <auth-constraint> clause can access the protected resource). • List all possible roles in block <security-role> of <web-app…> <web-app …> <security-constraint>…</security-constraint> <security-role> <role-name>sprole</role-name> <role-name>admin</role-name> <role-name>user</role-name> </security-role> <…/web-app> Web Application Security

21. Steps for the BASIC Authentication (5) Step 5. Specify the URLs that require SSL. When users access the specified directory, the server redirects requests to https. • Add <transport-guarantee> block under <user-data-constraint> in <security-constraint> with value CONFIDENTIAL. <security-constraint> … <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> … </security-constraint> Web Application Security

22. Do you like BASIC Authentication? • Is BASIC authentication good enough? • Disadvantages • No customization is allowed (e.g. no user defined GUI or login pages) • Can only get username and password by default Web Application Security

23. Form-based Authentication Web server collects user identification information via a customized login page, e.g. Web Application Security

24. Steps for Form-based Authentication (1) Step 1. Setup realms (username, password and role) • Same as the BASIC authentication Step 2a. Specify the user of Form-based authentication • In web.xml of your web application <web-app …> <security-constraint>…</security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>Form-based authentication Example</realm-name> <form-login-config> <form-login-page>/html/login.html</form-login-page> <form-error-page>/html/login-error.html</form-error-page> </form-login-config> </login-config> <… /web-app> Specify the location of the login and login-error pages (under /WEB-INF/html directory) Web Application Security

25. Steps for Form-based Authentication (2) Step 2b. Create customized login page • Can be HTML or JSP page as below: • HTML form must have ACTION of j_security_check, METHOD of POST, textfield named j_username, and password field named j_password as following: Source code: <form action="j_security_check" method="POST"> <p>User name: <input type="text" name="j_username" id="j_username" /></p> <p>Password: <input type="password" name="j_password" id="j_password" /></p> <p><input type="submit" value="Login" /></p> </form> Web Application Security

26. Steps for Form-based Authentication (3) • Step 2c. Create login failure page • Can be HTML or JSP page, simply for login failure messages Web Application Security

27. Steps for Form-based Authentication Step 3. Specify URLs (file paths) that should be password protected Step 4. List all possible abstract roles that will be granted access to the resource Step 5. Specify the URLs that require SSL • All the above 3 steps are the same as the BASIC authentication. Web Application Security

28. Basic vs. Form-based Authentication Web Application Security

29. Problems with pure declarative security • Access is all-or-nothing • Users can access a resource or be denied access to it. • No options to permit resources to customize their output depending on the username or role of the client that accesses them (i.e. partial access to information) • Access based on exact password matches • Controlled by server and is case non-sensitive. • Involves server-specific component • It is not completely portable. Different servers may have different ways of settings. • All pages use same mechanism • Cannot mix form-based and BASIC in same Web application. (not flexible) Web Application Security

30. Combined Declarative with Programming Security • Rely on the web-server for authentication (i.e., usernames, passwords, and roles) • Use Form-based or BASIC authentication • Access control by programs in the servlets or JSP pages • E.g. you can change the result of a particular page depending on who accesses it. With pure declarative security, it is all or nothing. • Use the following HttpServletRequest methods • isUserInRole: check if the current user is in a specified role, e.g., req.isUserInRole("admin"); • getRemoteUser: return the user-name who makes this request, e.g., name = req.getRemoteUser(); • getUserPrincipal: return a java.security.Principal object containing the name of authenticated user, e.g.,name =req.getUserPrincipal().getName(); Web Application Security

31. Combined Security Method • Follow the steps of setting up authentication (use either FORM or BASIC method) • Server can track users and pop up dialog box if they are unauthenticated Web Application Security

32. Servlet Program in Combined Security Servlet program segment • Specify the information to be accessed by “admin” role users only (NOTE: web.xml specifies access to both sprole or admin) String name = getRemoteUser(); if (name == null) out.println(name + " haven't logged in. <br>" ); else out.println("Hello, " + name + "! <br>"); if (request.isUserInRole(“admin")) { out.println("<H3>Administrator</H3>"); out.println("Median pay for corporate administrator:"); out.println("<UL>"); out.println(" <LI><B>2004:</B> $500,000."); out.println(" <LI><B>2005:</B> $600,000."); ………… out.println("</UL>"); } Web Application Security

33. Output of the Servlet Program Data accessed by ordinary users (“sprole” and “admin”) and by admin user only: Web Application Security

34. Pure Programming Security • Authentication & access control are all done by programs. NO need to setup security in conf files, server.xml, tomcat-users.xml, web.xml. • Advantages • Totally portable (No server-specific component) • Permits custom password-matching strategies • Disadvantages • Much harder to write programs and maintain • Every resource has to use programmed access control • You can build reusable infrastructure (e.g., servlets that inherit from certain class or custom JSP tags), but it is still a lot of work Web Application Security

35. Steps of Programming Security • Use your own database (or other data structure) to store usernames and passwords, and use “getParameter” to collect username and password from client for matching. • Use sessions to track the users that are already logined to the system. • Turn on SSL by using “https” (instead of “http”) of the web-server in the HTML form (when specifying URL of CGI to process the username/passwd form). Web Application Security

36. Programming Authentication with Session Tracking: an example protectedvoid doGet(…)… {            // Get the login name and password     String loginName = request.getParameter("UserName");            String password = request.getParameter("Password");         HttpSession session = request.getSession(true);            String xmlResult = "<ServerResponse>";    if (loginName.equals(password)) {                xmlResult += "<LoginResult>Login Success</LoginResult>";                session.setAttribute("Logined", new Boolean(true));            } else {                xmlResult += "<LoginResult>Login Fail</LoginResult>";                session.setAttribute("Logined", new Boolean(false));            }            xmlResult += "</ServerResponse>";            System.out.println("XML Result for Login Servlet: " + xmlResult);            out.print(xmlResult);        }    Web Application Security

37. Programming Security with SSL • Determining If SSL Is in Use • request.getScheme() //returns “https” or “http” • request.isSecure() //returns true or false • Redirecting to an SSL weblink • response.sendRedirect(“https://www.xyz.com/abc.jsp”) • Discovering the key-size (Number of bits in the Key) • request.getAttribute(“javax.servlet.request.key_size”) • Looking Up the Encryption Algorithm • request.getAttribute(“javax.servlet.request.cipher_suite”) • Accessing Client X509 Certificates • request.getAttribute(“javax.servlet.request.X509Certificate”) Web Application Security

38. Using Programming Security with SSL If HTTP is in use, redirect the web page over HTTPS automatically Print out information by using the functions described in the previous slide Web Application Security

39. Summary • Declarative security • Requires security configuration and no programming required. • BASIC authentication • Use standard login dialog box. • Form-based authentication • User customized login page. • Combined security • Use isUserRole or getRemoteUser for access control depending on who accesses resource • Still rely on server for authentication • Pure program security • User has full control of authentication (passwd match) and access control Web Application Security