Upload
shadi
View
53
Download
0
Embed Size (px)
DESCRIPTION
Web Application Security Workshop. James Walden. 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 - PowerPoint PPT Presentation
Citation preview
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
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 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.
4. Leakage of sensitive information.
5. Legal consequences of losing PII.
6. PR consequences of losing PII.
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.
3. Leakage of sensitive information.
4. Legal consequences of losing PII.
5. PR consequences of losing PII.
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
1. Leakage of sensitive information.
2. Legal consequences of losing PII.
3. PR consequences of losing PII.
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
1. Attackers can hijack user accounts.
2. Attacker can do anything a user can do.
3. Leakage of sensitive information.
4. Legal consequences of losing PII.
5. PR consequences of losing PII.
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.