Download ppt - Web Application Security Workshop

June 14, 2007

Web Application Security Workshop

James Walden

April 12, 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

Port 80HTTP Traffic

WebClient

WebServer

Application

Application

DatabaseServer

April 12, 2007

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

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

Software Vulnerabilities

Year

Vu

lne

rab

iliti

es

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. App sends form to user.2. Attacker submits form

with SQL exploit data.3. Application builds string

with exploit data.4. Application sends SQL

query to DB.5. DB executes query,

including exploit, sends data back to application.

6. Application returns data to user.

Attacker

Web Server DB Server

Firewall

User

Pass

‘ or 1=1--

April 12, 2007

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_cmdshell ‘cmd.exe format c: /q /yes’ --

Formats C: drive of database server if you’re running MS SQL Server and extended procedures aren’t disabled.

April 12, 2007

SQL Injection Demo

April 12, 2007

Impact of SQL Injection

1. Leakage of sensitive information.

2. Legal consequences of losing PII.

3. PR consequences of losing PII.

4. Modification of sensitive information.

5. Loss of sensitive information.

6. 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 MitigationsBlacklists

Stored Procedures

Effective MitigationsWhitelists

Prepared Queries

April 12, 2007

Ineffective Mitigation: Blacklist

Filter out known bad SQL metacharacters,such as single quotes.

Problems:1. Numeric parameters don’t use quotes.

2. URL escaped metacharacters.

3. Unicode encoded metacharacters.

4. Did you miss any metacharacters?

5. 2nd Order SQL Injection.

April 12, 2007

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, .NETDTDs for XML documents

Key IdeaAttacker controls pathname for inclusion.

April 12, 2007

Impact of Remote File Inclusion

1. Loss of control of web application.

2. Installation of malware.

3. Attacks launched against other sites.

4. Denial of service.

April 12, 2007

Mitigating Remote File Inclusion

1. Turn off remote file inclusion.

2. Do not run code from uploaded files.

3. Do not use user-supplied paths.

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

View

Output encoding.

Controller

General input validation.

Model

Model-specific validation.

ValidationRules

View Selection

StateChange

User Input

StateQuery Change

Notice

April 12, 2007

Validating Input

Check that input matches specified:Data typeCharacter set Input lengthNULLs or empty strings allowed?Numeric rangeList of legal valuesList of patterns

April 12, 2007

Impact of Unvalidated Input

1. More input-related vulnerabilities.

2. Loss of application integrity.

3. Loss of sensitive information.

4. Effort required to patch individual input-related 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

1. Login

2.

Cookie

Web Server

3. XSS Attack

Attacker User

4. User clicks on XSS link.

5. XSS URL

7. Browser runs injected code.

Evil site saves ID.

8. Attacker hijacks user session.

6. Page with injected code.

April 12, 2007

XSS URL Examples

http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><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>alert(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_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

April 12, 2007

Why does XSS Work?

Same-Origin PolicyBrowser 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 ProgramAny program that returns user input without

filtering out dangerous code.

April 12, 2007

Impact of XSS

1. Attackers can hijack user accounts.

2. Attackers can hijack admin accounts too.

3. Attacker can do anything a user can do.

4. Difficult to track down source of attack.

April 12, 2007

Mitigating XSS

1. Disallow HTML input2. Allow only safe HTML tags3. Filter output

Replace HTML special characters in outputex: replace < with < and > with >also replace (, ), #, &

4. Tagged cookiesInclude 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 IdeasHTTP 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 passwordsGuessing passwordsIdentity management attacksReplay attacksSession ID fixationSession ID guessing

April 12, 2007

Impact of Authentication Attacks


2. Attackers can hijack admin accounts too.


4. 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 controlSiteURLFunctionFunction(parameters)Data

April 12, 2007

Impact of Broken Access Control

1. Access to other customer’s accounts.

2. Execute code as other users.

3. Execute administrative code.




April 12, 2007

Mitigating Broken Access Control

1. Check every access.

2. Use whitelist model at every layer.

3. Do not rely on client-level access control.

4. 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 dataStack tracesSQL statementsSubsystem errorsUser typos, such as passwords.

April 12, 2007

Impact of Improper Error Handling

1. Returning user input can create a cross-site vulnerability.

2. Information leakage can increase the probability of a successful attack against the application.




April 12, 2007

Mitigating Improper Error Handling

1. Catch all exceptions.

2. Check all error codes.

3. Wrap application with catch-all handler.

4. Send user-friendly message to user.

5. Store details for debugging in log files.

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

ProblemsNot 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




April 12, 2007

Storage Recommendations

Hash algorithmsMD5 and SHA1 look insecure.Use SHA256.

Encrypting dataUse AES with 128-bit keys.

Key generationGenerate random keys.Use secure random source.

April 12, 2007

Mitigating Insecure Storage

1. Use well studied public algorithms.

2. Use truly random keys.

3. Store keys in protected files.

4. Review code to ensure that all sensitive data is being encrypted.

5. 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 vice-versa.

Need to protectUser authentication and session data.Sensitive data (CC numbers, SSNs)

Key IdeaUse SSL for all authentication connections.

April 12, 2007

Impact of Insecure Communication






April 12, 2007

Mitigating Insecure Communication

1. Use SSL for all authenticated sessions.

2. Use SSL for all sensitive data.

3. Verify that SSL is used with automated vulnerability scanning tools.

April 12, 2007

Going Further

April 12, 2007

References

1. Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment, Addison-Wesley, 2007.

2. “Java Gotchas,” http://mindprod.com/jgloss/gotchas.html, 2007.3. Mitre, Common Weaknesses – Vulnerability Trends,

http://cwe.mitre.org/documents/vuln-trends.html, 2007.4. Gary McGraw, Software Security, Addison-Wesley, 2006.5. J.D. Meier, et. al., Improving Web Application Security: Threats and

Countermeasures, Microsoft, http://msdn2.microsoft.com/en-us/library/aa302418.aspx, 2006.

6. OWASP Top 10, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2007.

7. Ivan Ristic, Web Application Firewalls: When Are They Useful?, OWASP AppSec EU 2006.

8. Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed: Web Applications, 2nd edition, Addison-Wesley, 2006.