Embed Size (px)
Citation preview
August 1, 2006
Traditional Security is Reactive
• Perimeter defense (firewalls)
• Intrusion detection• Over-reliance on
cryptography• Penetrate and patch• Penetration testing
August 1, 2006
The Problem is Software
“75 percent of hacks happen at the application.”
Theresa Lanowitz, Gartner Inc.
August 1, 2006
Hackers
“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
August 1, 2006
Developers Aren’t Ready
“64% of developers are not confident in their ability to write secure applications”
Bill Gates, RSA 2005
August 1, 2006
A Growing Problem
Software Vulnerabilities
1090
2437
41293784 3780
5690
0
1000
2000
3000
4000
5000
6000
2000 2001 2002 2003 2004 2005
August 1, 2006
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.
August 1, 2006
Vulnerabilities and Threats
Vulnerability: A bug or flaw in a system that makes an attack possible.
Threat: A party with the capability and intention to exploit a vulnerability.
August 1, 2006
OWASP Top 10 Vulnerabilities
1. Unvalidated Input – Information from web requests is not validated before
being used by a web application. Attackers can use these flaws to attack backend components through a web application.
2. Broken Access Control – Restrictions on what authenticated users are allowed to do
are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.
August 1, 2006
OWASP Top 10 Vulnerabilities
3. Broken Authentication and Session Management – Account credentials and session tokens are not properly
protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.
4. Cross Site Scripting – The web application can be used as a mechanism to
transport an attack to an end user's browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user.
August 1, 2006
OWASP Top 10 Vulnerabilities
5. Buffer Overflow – Web application components in some languages that do not
properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.
6. Injection Flaws – Web applications pass parameters when they access
external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
August 1, 2006
OWASP Top 10 Vulnerabilities
7. Improper Error Handling – Error conditions that occur during normal operation are not
handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
8. Insecure Storage – Web applications frequently use cryptographic functions to
protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
August 1, 2006
OWASP Top 10 Vulnerabilities
9. Application Denial of Service – Attackers can consume web application resources to a
point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.
10. Insecure Configuration Management – Having a strong server configuration standard is critical to
a secure web application. These servers have many configuration options that affect security and are not secure out of the box.
August 1, 2006
SQL Injectionuse DBI;
$dbh = DBI->connect($conn, $dbusername, $dbpassword) or die “Database connection failed.\n”;$sql = “SELECT count(*) from users where username =
‘$username’ and password = ‘$password’”;$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;$sth->execute() or die “Execute failed.\n”;
What if user gives SQL code as name or password?
August 1, 2006
SQL Metacharacters
‘ quotes parameters
; separates commands
-- comments
%, _ glob in LIKE clause
%, _, *, +, |, [], () used for regular expressions in SIMILAR TO clause
August 1, 2006
SQL Injection Attack #1
• 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.
August 1, 2006
SQL Injection Attack #2
• Database Modification Attack:– password = foo’; delete from table users where
username like ‘%
• Database executes two SQL statements:– select count(*) from users where username =
‘user’ and password = ‘foo’– delete from table users where username like ‘%’
August 1, 2006
Beyond the Database
• ODBC allows shell injection via “|”– ‘|shell(“cmd /c echo “ & chr(124) & “format
c:”)|’
• MS SQL Server Extended Stored Procs– Shell: exec master..xp_cmdshell ‘format c:’– Create new DB accounts: xp_grantlogin– Read any file: bulk insert foo from “c:\d.txt”
August 1, 2006
The Problem: String BuildingBuilding a SQL command string with user input in any language is dangerous.
– Variable interpolation.– String concatentation with variables.– String format functions like sprintf().– String templating with variable replacement.
August 1, 2006
Bad Solution #1: Blacklist
Attempted solution: Blacklist SQLmetacharacters, especially single quotes.
Problems:1. Numeric parameters don’t use quotes.
2. Database-escaped quotes: \’
3. URL escaped metacharacters.
4. Unicode encoded metacharacters.
5. Did you miss any metacharacters?
6. 2nd Order SQL Injection.
August 1, 2006
Numeric Parameters
• Solution: Escape single quotes
• Problem #1: What if you use stored user data?– Q: select count(*) from users where uid=$uid– User enters uid = 1 or 1=1– Query becomes:
• select count(*) from users where uid=1 or 1=1• Once again, this query is always true.
August 1, 2006
2nd Order SQL Injection
• Solution: Escape single quotes• Problem #2: What if you use stored user data?
– User creates account with user = root’--
– Application escapes and inserts as root’’--
– User resets password.
– Your query fetches username from DB to verify account exists with correct old password.
– update users set password=‘pass’ where username = ‘root’--’
August 1, 2006
Bad Solution #2: Stored ProceduresSQL 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
August 1, 2006
Solution: Prepared Queriesuse DBI;
$dbh = DBI->connect(conn(), $db_username, $db_password) or
die “Database connection failed.\n”;
$sql = “SELECT count(*) from users where username = ? and password = ?”;
$sth = $dbh->prepare($sql) or die “Prepare failed.\n”;
$sth->bind_param(1, $username);
$sth->bind_param(2, $password);
$sth->execute() or die “Execute failed.\n”;
August 1, 2006
Additional Precautions
1. Don’t access the DB as a privileged user.
2. Don’t allow access to DB from Internet.
3. Don’t embed DB passwords in your code.
4. Don’t leak information in error messages.
August 1, 2006
Going Further
• Reading– OWASP Top 10 Project– OWASP Guide– Hacking Web Applications Exposed, 2/e
• Software– WebGoat (OWASP)– Hacme Bank (Foundstone)– MasterBugs
August 1, 2006
References1. Stephen J. Friedl, “SQL Injection Attacks by Example,”
http://www.unixwiz.net/techtips/sql-injection.html, 2005.2. Gary McGraw, Software Security, Addison-Wesley, 2006.3. Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security,
McGraw-Hill Osborne, 2005.4. Michael Howard, David LeBlanc, Writing Secure Code, 2nd edition, Microsoft Press, 2003.5. Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press,
2006.6. OWASP, The OWASP Top 10 Project,
http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2006.7. OWASP, The OWASP Guide to Building Secure Web Applications,
http://www.owasp.org/index.php/OWASP_Guide_Project, 2006.8. Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2nd
edition, Addison-Wesley, 2006.9. SK, “SQL Injection Walkthrough,”
http://www.securiteam.com/securityreviews/5DP0N1P76E.html, 2002.10. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002.
