1. SE-2840 Dr. Mark L. Hornick1 Web Application Security

2. There are three main security concerns your web apps need to address Eavesdropping A third-party gains access to confidential information exchanged between your site and a valid user Your site needs to encrypt communication to prevent this Impersonation A client pretends to be someone else in order to gain access to your site Your site needs to authenticate clients to prevent this Upgrading A client gains access to restricted aspects of your web app The client may be authenticated, but not authorized Your site needs to authorize clients to access privileged information SE-2840 Dr. Mark L. Hornick2

3. Don’t try to implement security yourself You are unlikely to get it right unless you are an absolute expert Leave it to experts and use well-accepted approaches CS-4220 Dr. Mark L. Hornick3

4. All of these can be managed via the Deployment Descriptor SE-2840 Dr. Mark L. Hornick4 Tomcat incorporates a declarative security model that requires no changes to your Servlets or pages Tomcat itself handles Authentication, Authorization, and Data Encryption

5. Types of Encryption One-way hash Data can be encrypted, but not unencrypted Asymmetric keys Data encrypted with a public key can only be decrypted with a private key, and vice-versa Computationally intensive Symmetric keys Encryption and decryption use the same key Computationally simpler CS-4220 Dr. Mark L. Hornick5 “Hello” 7sdf08df7sdlf0d98s230d “Hello” sdfs09deo0e93 “Hello” 9sd8sas09dd89 “Hello”65kl54jdo48xd “Hello”

6. Encrypting the transport of data ensures that sensitive data (eg. passwords) will not be viewable during transmission either to or from the server SE-2840 Dr. Mark L. Hornick6 <!-- This section declares specific resources whose access is to be constrained by the Tomcat security manager. --> SecuredPages /MyApp/somepage.html /MyApp/page2.jsp /MyApp/myServlet <!-- This specifies that the browser and server establish an encrypted Connection for exchanging request and response data --> CONFIDENTIAL... The default transport is NONE

7. SSL Encryption requires the exchange of keys between the browser and server The browser asks the server for its public key The server delivers the public key enclosed in a certificate that contains the server’s information The browser checks to see if the certificate is valid by consulting a root certificate authority The user is given a chance to intervene Simplified: The browser accepts the certificate and the server’s enclosed public key, generates a “secret” and sends the secret to the server, encrypted with the server’s public key The server decrypts the secret with its private key The shared secret is used to encrypt subsequent exchanged messages The secret is discarded at the end of the session CS-4220 Dr. Mark L. Hornick7

8. The server.xml file contains configuration specifications for Tomcat operation, including enabling HTTPS (SSL): SE-2840 Dr. Mark L. Hornick8 <!-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation --> <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile=“C:/Apache/keystore" keystorePass="changeit" clientAuth="false" sslProtocol="TLS" /> Note: the blue text is (usually) already in this file, although commented out. I rearranged the comments and added the green line that specifies the file containing the generated Certificate.

9. Key generation Demo SE-2840 Dr. Mark L. Hornick9

10. Generating a certificate (See http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html) SE-2840 Dr. Mark L. Hornick10 Note: When prompted for the password, I entered “changeit”

11. CS-4220 Dr. Mark L. Hornick11

12. CS-4220 Dr. Mark L. Hornick12

13. SE-2840 Dr. Mark L. Hornick13

14. admin member <!-- This section declares specific resources to be accessible only by users in certain roles (defined in the separate tomcat-users.xml file. --> SecuredPages /MyApp/admin.jsp /MyApp/manage.jsp... Admin Manager... Authorization allows a web app to restrict access to specific parts of an application SE-2840 Dr. Mark L. Hornick14

15. Authorization requires Authentication so that a web app can validate the identity of a client SE-2840 Dr. Mark L. Hornick15 admin member SecuredPages /MyApp/admin.jsp /MyApp/manage.jsp admin manager <!– When you specify a login-config, the container automatically supplies a username/password prompt --> BASIC

16. The tomcat-users.xml file contains role, username, and password definitions: SE-2840 Dr. Mark L. Hornick16 <!-- NOTE: By default, no user is included in the "manager" role required to operate the "/manager" web application. If you wish to use this app, you must define such a user - the username and password are arbitrary. --> <!-- NOTE: The sample user and role entries below are wrapped in a comment and thus are ignored when reading this file. Do not forget to remove that surrounds them. --> <!-- -->

17. Tomcat-users.xml Demo SE-2840 Dr. Mark L. Hornick17

18. Basic login Demo SE-2840 Dr. Mark L. Hornick18

19. admin member SecuredPages /MyApp/admin.jsp /MyApp/manage.jsp Admin Manager CONFIDENTIAL FORM /autologin.html /autologinError.html You can define your own login page if you don’t like the default popup dialog: SE-2840 Dr. Mark L. Hornick19

20. Login please username: password: The login form must use the indicated action and input field names: SE-2840 Dr. Mark L. Hornick20