Java Web Programming [9/9] : Web Application Security

1,033 views

Published on

Presentation for Java Web Programming Course; 2011

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,033
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
82
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Java Web Programming [9/9] : Web Application Security

  1. 1. Module 9: Web Application Security Thanisa Kruawaisayawan Thanachart Numnonda www.imcinstitute.com
  2. 2. Objectives General security issues  Authentication  Authorization  Data Integrity  Confidentiality Web-tier Authentication Schemes  BASIC  DIGEST  FORM  CLIENT-CERT Declarative Authorization 2
  3. 3. General Security Issues Authentication for identity verification Making sure a user is who he claims he is Authorization (Access control) Making sure resources are accessible only to users who have access privilege The user has to be authenticated first Data Integrity - Making suere that information has not been modified by a third party while in transit. Confidentiality (Privacy) Protecting the sensitive data from prying eyes while it is on the wire 3
  4. 4. Security Requirements at Web-Tier Preventing unauthorized users from accessing “access controlled” web resource If an unauthenticated user tries to access “access controlled” web resource, web container will automatically ask the user to authenticate himself first Once the user authenticated, web container (and/or web components) then enforces access control Preventing attackers from changing or reading sensitive data while it is on the wire Data can be protected via SSL 4
  5. 5. Web-Tier Security Scheme Should Address “Authentication”1. Collecting user identity information from an end user typically through browser interface user identity information usually means username and password this is called “logging in”1. Transporting collected user identity information to the web server unsecurely (HTTP) or securely (HTTP over SSL) 5
  6. 6. Web-Tier Security Scheme Should Address “Authentication” (cont.)1. Performing identity checking with backend “security database” (Realms) Web container checks if collected user identity matches with the one in the backend “security database” These backend “security database” are called Realms Realms maintain  Username, password, roles, etc. How these realms are organized and managed are product and operational environment dependent  LDAP, RDBMS, Flat-file, Solaris PAM, Windows AD 6
  7. 7. Web-Tier Security Scheme Should Address “Authentication” (cont.)1. Web container keep track of previously authenticated users for further HTTP operations Using internally maintained session state, web container knows if the caller of subsequent HTTP requests has been authenticated Web container also creates HttpServletRequest object for subsequent HTTP requests  HttpServletRequest object contains “security context” information Principal, Role, Username 7
  8. 8. Web-Tier Security Scheme Should Address “Access control” Web application developer and/or deployer specifies access control to web resources Declarative and/or Programmatic access control 8
  9. 9. Web-Tier Security Scheme Should Address “Data confidentiality” Providing confidentiality of the sensitive data that is being transported over the wire Between browser and web server Example: Credit card number Using SSL 9
  10. 10. Web-tier Authentication Schemes1. HTTP Basic Authentication2. HTTP Digest Authentication3. Form-based Authentication4. HTTPS Client Authentication 10
  11. 11. 1. HTTP Basic Authentication Web server collects user identification (user name and password) through a browser provided dialog box Not secure since user name and password are in “easily decodeable” form over the wire Encoding scheme is Base64 Someone can easily decode it Not encrypted Would need SSL for encrypting password 11
  12. 12. Steps for Basic Authentication-based Web-tier Security1. Set up username, passwords, and roles (realms)2. Tell web container that you are using Basic authentication3. Specify which URLs (web resources) should be access- controlled (password-protected)4. Specify which URLs should be available only with SSL (data integrity and confidentiality protected) 12
  13. 13. Step 1: Set up username, passwords, and roles (Realms) Schemes, APIs, and tools for setting up usernames, passwords, and roles (realms) are web container and operational environment specific Flat-file based, Database, LDAP server Passwords could be in either encrypted or unencrypted form Tomcat 4.0 can work with the following realms default: file, unencrypted form Relational database (via JDBCRealm) LDAP server (via LDAPRealm) 13
  14. 14. Example: Tomcats default <install-dir>/conf/tomcat-users.xml Unencrypted: not secure but easy to set up and maintain <?xml version=1.0 encoding=utf-8?> <tomcat-users> <role rolename="manager"/> <role rolename="admin"/> <role rolename="user"/> <user username="kmitl" password="kmitl" roles="user" /> <user username="root" password="root" roles="manager,admin" /> </tomcat-users> 14
  15. 15. Step 2: Tell web container that you are using Basic authentication In web.xml file of your web application <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app> 15
  16. 16. Step 3: Specify which URLs should be access-controlled<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/loadpricelist</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name></realm-name> </login-config> ...</web-app> 16
  17. 17. Step 4: Specify which URLs should be available only with SSL<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/loadpricelist</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name></realm-name> </login-config> ... 17</web-app>
  18. 18. 2. HTTP Digest Authentication HTTP digest authentication  The HTTP digest authentication also gets the username/password details in a manner similar to that of basic authentication.  However, the authentication is performed by transmitting the password in an encrypted form.  Only some Web browsers and containers support it. 18
  19. 19. 3. Form-based Authentication Web application collects user identification (user name, password, and other information) through a custom login page Not secure since user name and password are in “easily decodeable” form over the wire Encoding scheme is Base64 Someone can easily decode it Not encrypted Would need SSL for encrypting password 19
  20. 20. Form-Based Auth. Control Flow Request Response Page Login Error Page Form 1 7 4 5 9 Protected Login.jsp j_security_check Error.html 2 Resource 3 6 81. Request made by client 6. Authentication Login succeeded,2. Is client authenticated? redirected to resource 7. Authorization Permission tested,3. Unauthenticated client result returned redirected 8. Login failed, redirect to error page4 . L og i n f or m r et u r n ed t o cl i en t 9. Error page returned to client5. Client submits login form 20
  21. 21. Steps for Form-based Authentication based Web-tier Security1. Set up username, passwords, and roles (realms): Same as in Basic-authentication2. Tell web container that you are using Form-based authentication3. Create custom “Login page”4. Create custom “Error page”5. Specify which URLs (web resources) should be access- controlled (password-protected)6. Specify which URLs should be available only with SSL (data integrity and confidentiality protected) 21
  22. 22. Step 2: Tell web container that you are using Form-based authentication In web.xml file of your web application <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app> 22
  23. 23. Step 3: Create custom “Login Page” Can be HTML or JSP page Contains HTML form like following <FORM ACTION="j_security_check" METHOD="POST"> <INPUT TYPE="TEXT" NAME="j_username"> <INPUT TYPE="PASSWORD" NAME="j_password"> </FORM> 23
  24. 24. Step 4: Create Error page Can be HTML or JSP page No specific content is mandated 24
  25. 25. Step 5: Specify which URLs should be access- controlled (Same as Basic Auth)<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/loadpricelist</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name></realm-name> </login-config> ...</web-app> 25
  26. 26. Step 6: Specify which URLs should be available only with SSL (Same as Basic Auth)<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/loadpricelist</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name></realm-name> </login-config> ...</web-app> 26
  27. 27. Basic and Form-based Form-based Basic Form-based• Uses “browser provided • Uses “web application dialog box” to get provided login page” to username and get username and password password• Only username and • Custom data can be password can be collected collected • Can enforce consistent• Might result in different look and feel look and feel • Form data is used to• HTTP Authentication convey username and header is used to password convey username and • Can enter a new user password name via login page• No good way to enter a 27
  28. 28. 4. HTTPS Client Authentication HTTPS client authentication  End-user authentication using HTTP over SSL (HTTPS) requires the user to possess a public key certificate (PKC).  All the data is transmitted after incorporating public key encryption.  It is the most secure authentication type.  It is supported by all the common browsers. 28
  29. 29. Confidentiality of Passwords For Basic and Form-based authentication, unless explicitly specified, the password gets transported in unencrypted form (Base64) The <transport-guarantee> element can contain any of three values:  NONE means no transport guarantee  INTEGRAL means data cannot be changed in transit  CONFIDENTIAL means the contents of a transmission cannot be observed Example: <user-data-constraint> <description> Integral Transmission </description> <transport-guarantee>INTEGRAL</transport-guarantee> </user-data-constraint> 29
  30. 30. Steps for Declarative Authorization at Web-tier1. Deployer maps actual user identities to security roles using vendor specific tools2. Deployer declares security roles in the deployment descriptor3. Deployer declares URL permissions in the deployment descriptor for each security roleThis is already covered above under “Web-tier security schemes” segment! 30
  31. 31. Declarative and Programmatic Authorization (Access Control) They are usually used together Declarative access control for role-based access control Programmatic access control for user instance- based and business logic based access control  User instance  Time of the day  Parameters of the request  Internal state of the web component 31
  32. 32. Steps for Programmatic Authorization at Web-tier1. Set up username, passwords, and roles (realms)2. Servlet programmer writes programmatic authorization logic inside the Servlet code using abstract security roles3. Deployer maps abstract security roles to actual roles (for a particular operational environment) in the web.xml 32
  33. 33. Step 2: Servlet Programmer writes programmatic authorization logicpublic interface javax.servlet.http.HTTPServletRequest{ ... // Find out who is accessing your web resource public java.security.Principal getUserPrincipal(); public String getRemoteUser(); // Is the caller in a particular role? public boolean isUserInRole(String role); ...} 33
  34. 34. Example: “Employees” can only access their own Salary Informationpublic double getSalary(String employeeId) { java.security.Principal userPrincipal = request.getUserPrincipal(); String callerId = userPrincipal.getName(); // “manager” role can read employee salary information // employee can read only his/her own salary information if ( (request.isUserInRole(“manager”)) || ((request.isUserInRole(“employee”)) && (callerId == employeeId)) ) { // return Salary information for theemployee getSalaryInformationSomehow(employeeId); } else { throw new SecurityException(“accessdenied”); } 34
  35. 35. Acknowledgement Most contents are borrowed from thepresentation slides of Sang Shin, Java™Technology Evangelist, Sun Microsystems,Inc.
  36. 36. Thank you thananum@gmail.comwww.facebook.com/imcinstitute www.imcinstitute.com 36

×