1. C HAPTER 12 W EB APP SECURITY

2. T HE BAD GUYS ARE EVERYWHERE As a web application developer you need to protect your web site There are three main kind of bad guys you need to watch out for: Impersonators Upgraders Eavesdroppers

3. E XAMPLE I MPERSONATOR

4. E XAMPLE U PGRADER

5. E XAMPLE E AVESDROPPER

6. T HE B IG 4 IN SERVLET SECURITY Servlet security boils down to four main concepts Authentication Verify the identity of the subject Authorization Give subject access to restricted resources Confidentiality Information is not leaked to persons who should not have the access Data integrity Data is not modified illegitimately

7. A UTHENTICATION

8. A UTHORIZATION

9. C ONFIDENTIALITY AND D ATA I NTEGRITY

10. H OW TO AUTHENTICATE IN HTTP W ORLD (B ASIC A UTHENTICATION )

12. C ONTAINER CAN CONTROL AUTHENTICATION AND AUTHORIZATION In stead of coding authentication and authorization in servlet and jsp programmatically, container can control authentication and authorization Thus the application developer do not have to write authentication and authorization logic for each individual serlvet and jsp program

13. H OW DID THE C ONTAINER DO THAT ? Perform a lookup on the resource being requested Find out whether the resource has security constraints Authenticate client Find out whether “Bob” really is Bob The Container has to see whether the user, say Bob, is allowed to access the resource

14. K EEP SECURITY OUT OF THE CODE For most web app, most of the time, the web app’s security constraints should be handled declaratively, in the deployment descriptor Why?

16. S ECURITY REALM As far as the servlet spec is concerned, a realm is a place where authentication information is stored When you are testing your application in Tomcat, you can use a file called tomcat-users.xml. This file is the realm. Also called memory realm because Tomcat reads this file into memory at startup time Disadvantage: You cannot modify the file’s content without restarting Tomcat

18. E NABLING AUTHENTICATION To get authentication working, you need to stick something in the Deployment Descriptor. To start using http basic authentication

19. A UTHORIZATION STEP 1: DEFINE ROLES Define the roles in a vendor-specific file tomcat- users.xml

20. A UTHORIZATION STEP 1: DEFINE ROLES Map the roles in the vendor-specific “users” file to roles established in the Deployment Descriptor

21. A UTHORIZATION STEP 2: DEFINING RESOURCE /HTTP METHOD CONSTRAINTS This is where we get to specify, declaratively, that a given resource/method combination is accessible only by users in certain roles

23. T HE RULES FOR ELEMENTS The purpose of the sub-element is to tell the container which resources and HTTP method combinations should be constrained in such a way that they can be accessed only by the roles in the corresponding tag

27. U SE PROGRAMMATIC SECURITY WITH DECLARATIVE SECURITY FOR FINE - GRAINED SECURITY CONTROL In stead of authorizing at the HTTP method level (GET, POST, etc.), you can customize a service method to behave based on the user’s role Suppose we defined the role “Manager” in the DD, the following code customize the response to the Manager if (request.isUserInRole(“Manager”)){ //show info related to all employees …… } else { //show info only related to a particular employee …… }

28. F OUR AUTHENTICATION TYPES BASIC Transmits the login information in an encoded (not encrypted) form Encoding scheme: base64 Very weak security DIGEST Authentication transmits the login information in a more secure way

29. F OUR AUTHENTICATION TYPES Client-CERT The client need to have a certificate before they can login to the system FORM FORM authentication lets you create your own custom login form out of anything that is legal HTML Form info is transmitted in the least secure way

30. F ORM - BASED AUTHENTICATION First, you create your own custom HTML form for the user login Then you create a custom HTML error page for the Container to use What you do:

31. F ORM - BASED AUTHENTICATION

33. S ECURING DATA IN TRANSIT :HTTPS TO THE RESCUE We can tell a J2EE container to guarantee data to be transmitted over a protected transport layer connection, i.e, use HTTPS To do that, we will use for both confidentiality and integrity by adding an element called in the DD for the application

35. S ECURING DATA IN TRANSIT :HTTPS TO THE RESCUE Tomcat supports HTTPS out of the box It won’t necessarily have HTTPS configured for your application automatically You still need to generate or apply for a certificate and then configure tomcat to use HTTPS You may refer to http://tomcat.apache.org/tomcat-6.0-doc/ssl- howto.htmlhttp://tomcat.apache.org/tomcat-6.0-doc/ssl- howto.html