Transcript COMPUTER INFORMATION TECHNOLOGY AT NKU

Web Application Security
Workshop
James Walden
June 14, 2007
About the Speaker
Background



Ph.D. from Carnegie Mellon University
10 years of secure development experience.
Gives workshops in secure programming and
software security at a variety of conferences.
Assistant Professor at NKU
 Specialize in software security.
 4 years experience teaching security.
April 12, 2007
What is web application security?
The art and science of developing web
applications that function correctly even
when under attack.
April 12, 2007
Firewalls don’t protect web apps
Firewall
Application
Web
Client
HTTP Traffic
April 12, 2007
Web
Server
Port 80
Application
Database
Server
What is web application security?
It’s more than just cryptography.

SSL won’t solve all your problems.
It’s more than securing the web server.

Web applications have their own problems.
It’s more than application firewalls.

Firewall can’t know every safe action at
every possible state in your application.
April 12, 2007
The source of the problem
“Malicious hackers don’t create security
holes; they simply exploit them. Security
holes and vulnerabilities – the real root
cause of the problem – are the result of
bad software design and
implementation.”
John Viega & Gary McGraw
April 12, 2007
Penetrate and Patch
Discover flaws after deployment.
Often by attackers.
Users may not deploy patches.
Patches may have security flaws (15%?)
Patches are maps to vulnerabilities.
Attackers reverse engineer to create attacks.
April 12, 2007
A Growing Problem
Software Vulnerabilities
9000
8000
Vulnerabilities
7000
6000
5000
4000
3000
2000
1000
0
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
Year
April 12, 2007
Vulnerability Trends for 2006
April 12, 2007
Web Application Vulnerabilities
Input-based Security Problems



Injection Flaws
Insecure Remote File Inclusion
Unvalidated Input
Authentication and Authorization



Cross-Site Scripting
Authentication
Access Control
Other Bugs



Error Handling and Information Leakage
Insecure Storage
Insecure Communications
April 12, 2007
Injection
Injection attacks trick an application into
including unintended commands in the
data send to an interpreter.
 Interpreters

Interpret strings as commands.
 Ex: SQL, shell (cmd.exe, bash), LDAP, XPath


Key Idea

Input data from the application is executed as
code by the interpreter.
April 12, 2007
SQL Injection
1.
2.
3.
4.
5.
6.
App sends form to user.
Attacker submits form
with SQL exploit data.
Application builds string
with exploit data.
Application sends SQL
query to DB.
DB executes query,
including exploit, sends
data back to application.
Application returns data
to user.
Attacker
User ‘ or 1=1-Pass
Firewall
Web Server
April 12, 2007
DB Server
SQL Injection in PHP
$link = mysql_connect($DB_HOST,
$DB_USERNAME, $DB_PASSWORD) or die
("Couldn't connect: " . mysql_error());
mysql_select_db($DB_DATABASE);
$query = "select count(*) from users where
username = '$username' and password =
'$password'";
$result = mysql_query($query);
April 12, 2007
SQL Injection Attack Example
Unauthorized Access Attempt:
password = ’ or 1=1 --
SQL statement becomes:
select count(*) from users where username
= ‘user’ and password = ‘’ or 1=1 -Checks if password is empty OR 1=1, which
is always true, permitting access.
April 12, 2007
Impact of SQL Injection
SELECT SSN FROM USERS WHERE UID=‘$UID’
INPUT
RESULT
5
Returns info for user with UID 5.
‘ OR 1=1--
Returns info for all users.
‘ UNION SELECT
Field FROM Table
WHERE 1=1--
Returns all rows from another table.
‘;DROP TABLE
USERS--
Deletes the users table.
‘;master.dbo.xp_c Formats C: drive of database server if you’re
mdshell ‘cmd.exe running MS SQL Server and extended
format c: /q /yes’ -- procedures aren’t disabled.
April 12, 2007
SQL Injection Demo
April 12, 2007
Impact of SQL Injection
1.
2.
3.
4.
5.
6.
Leakage of sensitive information.
Legal consequences of losing PII.
PR consequences of losing PII.
Modification of sensitive information.
Loss of sensitive information.
Denial of service against db server.
April 12, 2007
The Problem: String Building
Building a SQL command string with user
input in any language is dangerous.
•
•
•
•
Variable interpolation.
String concatenation with variables.
String format functions like sprintf().
String templating with variable
replacement.
April 12, 2007
Mitigating SQL Injection
Ineffective Mitigations
Blacklists
Stored Procedures
Effective Mitigations
Whitelists
Prepared Queries
April 12, 2007
Ineffective Mitigation: Blacklist
Filter out known bad SQL metacharacters,
such as single quotes.
Problems:
1.
2.
3.
4.
5.
April 12, 2007
Numeric parameters don’t use quotes.
URL escaped metacharacters.
Unicode encoded metacharacters.
Did you miss any metacharacters?
2nd Order SQL Injection.
Ineffective Mitigation: Stored Procedures
SQL Stored Procedures build strings too:
CREATE PROCEDURE dbo.doQuery(@id nchar(128)
AS
DECLARE @query nchar(256)
SELECT @query = ‘SELECT cc FROM cust WHERE id=‘’’ + @id +
‘’’’
EXEC @query
RETURN
April 12, 2007
Mitigation: Whitelist
Reject input that doesn’t match your list
of safe characters to accept.



Identify what’s good, not what’s bad.
Reject input instead of attempting to repair.
Still have to deal with single quotes when
required, such as in names.
April 12, 2007
Mitigation: Prepared Queries
require_once 'MDB2.php';
$mdb2 =& MDB2::factory($dsn, $options);
if (PEAR::isError($mdb2)) {
die($mdb2->getMessage());
}
$sql = “SELECT count(*) from users where username = ? and
password = ?”;
$types = array('text', 'text');
$sth = $mdb2->prepare($sql, $types, MDB2_PREPARE_MANIP);
$data = array($username, $password);
$sth->execute($data);
April 12, 2007
Insecure Remote File Inclusion
Insecure remote file inclusion
vulnerabilities allow an attack to trick the
application into executing code provided
by the attacker on another site.
 Dynamic code

Includes in PHP, Java, .NET
 DTDs for XML documents


Key Idea

Attacker controls pathname for inclusion.
April 12, 2007
Impact of Remote File Inclusion
1.
2.
3.
4.
Loss of control of web application.
Installation of malware.
Attacks launched against other sites.
Denial of service.
April 12, 2007
Mitigating Remote File Inclusion
1.
2.
3.
4.
Turn off remote file inclusion.
Do not run code from uploaded files.
Do not use user-supplied paths.
Validate all paths before loading code.
April 12, 2007
Unvalidated Input

Unvalidated input is an architecture flaw.
Individual input-related bugs are easy to fix.
 How do you defend against the general
problem of input-based attacks?


Key Ideas
Application needs to validate all input.
 Input validation needs to be part of design.

April 12, 2007
Input Validation Principles
All input must be validated.
 Input must be validated on the server.
 Use a standard set of validation rules.
 Reject all input that isn’t in your whitelist.

Blacklists can miss bad inputs.
 Input repairs can produce bad input.

April 12, 2007
Input Validation Architecture
Model
Model-specific
validation.
State
Query
Change
Notice
Validation
Rules
View
Output encoding.
View Selection
User Input
April 12, 2007
State
Change
Controller
General input
validation.
Validating Input
Check that input matches specified:
Data type
 Character set
 Input length
 NULLs or empty strings allowed?
 Numeric range
 List of legal values
 List of patterns

April 12, 2007
Impact of Unvalidated Input
1.
2.
3.
4.
More input-related vulnerabilities.
Loss of application integrity.
Loss of sensitive information.
Effort required to patch individual inputrelated bugs.
April 12, 2007
Mitigating Unvalidated Input

Design for input validation.
Architect app so all input is checked.
 Create a standard library of validation rules.
 Use a whitelist approach.

Educate developers about validation.
 Verify that all input is validated.

April 12, 2007
Cross-Site Scripting (XSS)

Attacker causes a legitimate web server to
send user executable content (Javascript, Flash
ActiveScript) of attacker’s choosing.
 XSS used to obtain session ID for



Bank site (transfer money to attacker)
Shopping site (buy goods for attacker)
Key ideas


Attacker sends malicious code to server.
Victim’s browser loads code from server and runs it.
April 12, 2007
Anatomy of an XSS Attack
Web Server
Attacker
User
3. XSS Attack
7. Browser runs
injected code.
4. User clicks on XSS link.
April 12, 2007
Evil site saves ID.
XSS URL Examples
http://www.microsoft.com/education/?ID=MCTN&target
=http://www.microsoft.com/education/?ID=MCTN&tar
get="><script>alert(document.cookie)</script>
http://hotwired.lycos.com/webmonkey/00/18/index3a_
page2.html?tw=<script>alert(‘Test’);</script>
http://www.shopnbc.com/listing.asp?qu=<script>aler
t(document.cookie)</script>&frompage=4&page=1&ct
=VVTV&mh=0&sh=0&RN=1
http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_sea
rch_exe?search_text=_%22%3E%3Cscript%3Ealert%28d
ocument.cookie%29%3C%2Fscript%3E
April 12, 2007
Why does XSS Work?
Same-Origin Policy
Browser only allows Javascript from site X to
access cookies and other data from site X.
 Attacker needs to make attack come from
site X.

Vulnerable Server Program

Any program that returns user input without
filtering out dangerous code.
April 12, 2007
Impact of XSS
1.
2.
3.
4.
Attackers can hijack user accounts.
Attackers can hijack admin accounts too.
Attacker can do anything a user can do.
Difficult to track down source of attack.
April 12, 2007
Mitigating XSS
1.
2.
3.
Disallow HTML input
Allow only safe HTML tags
Filter output
Replace HTML special characters in output
ex: replace < with &lt; and > with &gt;
also replace (, ), #, &
4.
Tagged cookies
Include IP address in cookie and only allow
access to original IP address that cookie was
created for.
April 12, 2007
Authentication
Authentication is the process of
determining a user’s identity.
 Key Ideas

HTTP is a stateless protocol.
 Every request must be authenticated.
 Use username/password on first request.
 Use session IDs on subsequent queries.

April 12, 2007
Authentication Attacks
Sniffing passwords
 Guessing passwords
 Identity management attacks
 Replay attacks
 Session ID fixation
 Session ID guessing

April 12, 2007
Impact of Authentication Attacks
1.
2.
3.
4.
Attackers can hijack user accounts.
Attackers can hijack admin accounts too.
Attacker can do anything a user can do.
Difficult to track down source of attack.
April 12, 2007
Mitigating Authentication Attacks
Use SSL to prevent sniffing attacks.
 Require strong passwords.
 Use secure identity management.
 Use a secure session ID mechanism.

IDs chosen at random from large space.
 Regenerate session IDs with each request.
 Expire session IDs in short time.

April 12, 2007
Access Control
Access control determines which users
have access to which system resources.
 Levels of access control

Site
 URL
 Function
 Function(parameters)
 Data

April 12, 2007
Impact of Broken Access Control
1.
2.
3.
4.
5.
6.
Access to other customer’s accounts.
Execute code as other users.
Execute administrative code.
Leakage of sensitive information.
Legal consequences of losing PII.
PR consequences of losing PII.
April 12, 2007
Mitigating Broken Access Control
1.
2.
3.
4.
Check every access.
Use whitelist model at every layer.
Do not rely on client-level access
control.
Do not rely on security through
obscurity.
April 12, 2007
Improper Error Handling
Applications can unintentionally leak
information about configuration,
architecture, or sensitive data when
handling errors improperly.
 Errors can provide too much data

Stack traces
 SQL statements
 Subsystem errors
 User typos, such as passwords.

April 12, 2007
Impact of Improper Error Handling
1.
2.
3.
4.
5.
Returning user input can create a
cross-site vulnerability.
Information leakage can increase the
probability of a successful attack
against the application.
Leakage of sensitive information.
Legal consequences of losing PII.
PR consequences of losing PII.
April 12, 2007
Mitigating Improper Error Handling
1.
2.
3.
4.
5.
6.
Catch all exceptions.
Check all error codes.
Wrap application with catch-all handler.
Send user-friendly message to user.
Store details for debugging in log files.
Don’t log passwords or other sensitive
data.
April 12, 2007
Insecure Storage
Storing sensitive data without encrypting
it, or using a weak encryption algorithm,
or using a strong encryption system
improperly.
 Problems

Not encrypting sensitive data.
 Using home grown cryptography.
 Insecure use of weak algorithms.
 Storing keys in code or unprotected files.

April 12, 2007
Impact of Insecure Storage
1.
2.
3.
Leakage of sensitive information.
Legal consequences of losing PII.
PR consequences of losing PII.
April 12, 2007
Storage Recommendations
Hash algorithms
MD5 and SHA1 look insecure.
 Use SHA256.

Encrypting data

Use AES with 128-bit keys.
Key generation
Generate random keys.
 Use secure random source.

April 12, 2007
Mitigating Insecure Storage
1.
2.
3.
4.
5.
Use well studied public algorithms.
Use truly random keys.
Store keys in protected files.
Review code to ensure that all sensitive
data is being encrypted.
Check database to ensure that all
sensitive data is being encrypted.
April 12, 2007
Insecure Communication
Applications fail to encrypt sensitive data
in transit from client to server and viceversa.
 Need to protect

User authentication and session data.
 Sensitive data (CC numbers, SSNs)


Key Idea

Use SSL for all authentication connections.
April 12, 2007
Impact of Insecure Communication
1.
2.
3.
4.
5.
Attackers can hijack user accounts.
Attacker can do anything a user can do.
Leakage of sensitive information.
Legal consequences of losing PII.
PR consequences of losing PII.
April 12, 2007
Mitigating Insecure Communication
1.
2.
3.
Use SSL for all authenticated sessions.
Use SSL for all sensitive data.
Verify that SSL is used with automated
vulnerability scanning tools.
April 12, 2007
Going Further
April 12, 2007
References
1.
2.
3.
4.
5.
6.
7.
8.
Mark Dowd, John McDonald, Justin Schuh, The Art of Software
Security Assessment, Addison-Wesley, 2007.
“Java Gotchas,” http://mindprod.com/jgloss/gotchas.html, 2007.
Mitre, Common Weaknesses – Vulnerability Trends,
http://cwe.mitre.org/documents/vuln-trends.html, 2007.
Gary McGraw, Software Security, Addison-Wesley, 2006.
J.D. Meier, et. al., Improving Web Application Security: Threats and
Countermeasures, Microsoft, http://msdn2.microsoft.com/enus/library/aa302418.aspx, 2006.
OWASP Top 10,
http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2007.
Ivan Ristic, Web Application Firewalls: When Are They Useful?,
OWASP AppSec EU 2006.
Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed:
Web Applications, 2nd edition, Addison-Wesley, 2006.
April 12, 2007